[f2fs-dev] [PATCH] f2fs: reuse inode_entry_slab in gc procedure for using slab more effectively
There are two slab cache inode_entry_slab and winode_slab using the same
structure as below:
struct dir_inode_entry {
struct list_head list; /* list head */
struct inode *inode;/* vfs inode pointer */
};
struct inode_entry {
struct list_head list;
struct inode *inode;
};
It's a little waste that the two cache can not share their memory space for each
other.
So in this patch we remove one redundant winode_slab slab cache, then use more
universal name struct inode_entry as remaining data structure name of slab,
finally we reuse the inode_entry_slab to store dirty dir item and gc item for
more effective.
Signed-off-by: Chao Yu
---
fs/f2fs/checkpoint.c | 18 +-
fs/f2fs/debug.c | 2 +-
fs/f2fs/f2fs.h | 14 +-
fs/f2fs/gc.c | 20 ++--
fs/f2fs/gc.h | 7 ++-
fs/f2fs/super.c | 8 +---
6 files changed, 24 insertions(+), 45 deletions(-)
diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 333..9f5317c 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -24,7 +24,7 @@
#include
static struct kmem_cache *ino_entry_slab;
-static struct kmem_cache *inode_entry_slab;
+struct kmem_cache *inode_entry_slab;
/*
* We guarantee no failure on the returned page.
@@ -673,7 +673,7 @@ fail_no_cp:
return -EINVAL;
}
-static int __add_dirty_inode(struct inode *inode, struct dir_inode_entry *new)
+static int __add_dirty_inode(struct inode *inode, struct inode_entry *new)
{
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
@@ -690,7 +690,7 @@ static int __add_dirty_inode(struct inode *inode, struct
dir_inode_entry *new)
void update_dirty_page(struct inode *inode, struct page *page)
{
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
- struct dir_inode_entry *new;
+ struct inode_entry *new;
int ret = 0;
if (!S_ISDIR(inode->i_mode) && !S_ISREG(inode->i_mode))
@@ -720,7 +720,7 @@ out:
void add_dirty_dir_inode(struct inode *inode)
{
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
- struct dir_inode_entry *new =
+ struct inode_entry *new =
f2fs_kmem_cache_alloc(inode_entry_slab, GFP_NOFS);
int ret = 0;
@@ -738,7 +738,7 @@ void add_dirty_dir_inode(struct inode *inode)
void remove_dirty_dir_inode(struct inode *inode)
{
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
- struct dir_inode_entry *entry;
+ struct inode_entry *entry;
if (!S_ISDIR(inode->i_mode))
return;
@@ -768,7 +768,7 @@ void remove_dirty_dir_inode(struct inode *inode)
void sync_dirty_dir_inodes(struct f2fs_sb_info *sbi)
{
struct list_head *head;
- struct dir_inode_entry *entry;
+ struct inode_entry *entry;
struct inode *inode;
retry:
if (unlikely(f2fs_cp_error(sbi)))
@@ -781,7 +781,7 @@ retry:
spin_unlock(&sbi->dir_inode_lock);
return;
}
- entry = list_entry(head->next, struct dir_inode_entry, list);
+ entry = list_entry(head->next, struct inode_entry, list);
inode = igrab(entry->inode);
spin_unlock(&sbi->dir_inode_lock);
if (inode) {
@@ -1107,8 +1107,8 @@ int __init create_checkpoint_caches(void)
sizeof(struct ino_entry));
if (!ino_entry_slab)
return -ENOMEM;
- inode_entry_slab = f2fs_kmem_cache_create("f2fs_dirty_dir_entry",
- sizeof(struct dir_inode_entry));
+ inode_entry_slab = f2fs_kmem_cache_create("f2fs_inode_entry",
+ sizeof(struct inode_entry));
if (!inode_entry_slab) {
kmem_cache_destroy(ino_entry_slab);
return -ENOMEM;
diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
index 2b64221..dd7835b 100644
--- a/fs/f2fs/debug.c
+++ b/fs/f2fs/debug.c
@@ -172,7 +172,7 @@ get_cache:
si->cache_mem += npages << PAGE_CACHE_SHIFT;
npages = META_MAPPING(sbi)->nrpages;
si->cache_mem += npages << PAGE_CACHE_SHIFT;
- si->cache_mem += sbi->n_dirty_dirs * sizeof(struct dir_inode_entry);
+ si->cache_mem += sbi->n_dirty_dirs * sizeof(struct inode_entry);
for (i = 0; i <= UPDATE_INO; i++)
si->cache_mem += sbi->im[i].ino_num * sizeof(struct ino_entry);
}
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 3226af0..c48847e 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -136,8 +136,14 @@ struct ino_entry {
nid_t ino; /* inode number */
};
-/* for the list of directory inodes */
-struct dir_inode_entry {
+/*
+ * for the list of directory inodes or gc inodes.
+ * NOTE: there are two slab users for this structure, if we add/modify/delete
+ * fields in structure for one of slab users, it may affect fields or size of
+ * other one, in this condition, it's better to split both of slab and related
+ * data structure.
+ */
+struct inode_entry {
struc
Re: [PATCH] perf: fix building error in x86_64 when dwarf unwind is on
Hi Wang,
(Adding Arnaldo and Jiri to CC)
On Sat, Dec 27, 2014 at 09:26:11AM +0800, Wang Nan wrote:
> When build with 'make ARCH=x86' and dwarf unwind is on, there is a
> compiling error:
>
>CC /home/wn/perf/arch/x86/util/unwind-libdw.o
>CC /home/wn/perf/arch/x86/tests/regs_load.o
> arch/x86/tests/regs_load.S: Assembler messages:
> arch/x86/tests/regs_load.S:65: Error: operand type mismatch for `push'
> arch/x86/tests/regs_load.S:72: Error: operand type mismatch for `pop'
> make[1]: *** [/home/wn/perf/arch/x86/tests/regs_load.o] Error 1
> make[1]: INTERNAL: Exiting with 25 jobserver tokens available; should be 24!
> make: *** [all] Error 2
> ...
>
> Which is caused by incorrectly undefine macro HAVE_ARCH_X86_64_SUPPORT.
> 'config/Makefile.arch' tests __x86_64__ only when 'ARCH=x86_64'. However,
> with 'ARCH=x86', the underlying compile may also be x86_64, which causes
> mismatching.
Hmm.. how did you compile this? I guess ARCH=x86 requires -m32 flag
to the gcc, did you pass it (like via EXTRA_CFLAGS=-m32)?
I'm confused by 'underlying compile may also be x86_64' part..
Thanks,
Namhyung
>
> This patch fixes it by checking __x86_64__ in both case of
> 'ARCH=x86_64' and 'ARCH=x86'.
>
> Signed-off-by: Wang Nan
> ---
> tools/perf/config/Makefile.arch | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/tools/perf/config/Makefile.arch b/tools/perf/config/Makefile.arch
> index 851cd01..303a096 100644
> --- a/tools/perf/config/Makefile.arch
> +++ b/tools/perf/config/Makefile.arch
> @@ -15,6 +15,8 @@ endif
>
> ifeq ($(ARCH),x86_64)
>override ARCH := x86
> +endif
> +ifeq ($(ARCH),x86)
>IS_X86_64 := 0
>ifeq (, $(findstring m32,$(CFLAGS)))
> IS_X86_64 := $(shell echo __x86_64__ | ${CC} -E -x c - | tail -n 1)
> --
> 1.8.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/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: arm: common: edma.c: Remove some unused functions
On 12/07/2014 12:53 AM, Rickard Strandqvist wrote:
> Removes some functions that are not used anywhere:
> edma_shadow0_read() edma_or_array()
>
> This was partially found by using a static code analysis program called
> cppcheck.
Acked-by: Peter Ujfalusi
>
> Signed-off-by: Rickard Strandqvist
> ---
> arch/arm/common/edma.c |8
> 1 file changed, 8 deletions(-)
>
> diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
> index d86771a..163273d 100644
> --- a/arch/arm/common/edma.c
> +++ b/arch/arm/common/edma.c
> @@ -160,10 +160,6 @@ static inline void edma_modify_array(unsigned ctlr, int
> offset, int i,
> {
> edma_modify(ctlr, offset + (i << 2), and, or);
> }
> -static inline void edma_or_array(unsigned ctlr, int offset, int i, unsigned
> or)
> -{
> - edma_or(ctlr, offset + (i << 2), or);
> -}
> static inline void edma_or_array2(unsigned ctlr, int offset, int i, int j,
> unsigned or)
> {
> @@ -174,10 +170,6 @@ static inline void edma_write_array2(unsigned ctlr, int
> offset, int i, int j,
> {
> edma_write(ctlr, offset + ((i*2 + j) << 2), val);
> }
> -static inline unsigned int edma_shadow0_read(unsigned ctlr, int offset)
> -{
> - return edma_read(ctlr, EDMA_SHADOW0 + offset);
> -}
> static inline unsigned int edma_shadow0_read_array(unsigned ctlr, int offset,
> int i)
> {
>
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next] net: stmmac: add BQL support
2014-12-28 6:57 GMT-08:00 Beniamino Galvani : > Add support for Byte Queue Limits to the STMicro MAC driver. > > Tested on a Amlogic S805 Cortex-A5 board, where the use of BQL > slightly decreases the ping latency from ~10ms to ~3ms when the > 100Mbps link is saturated by TCP streams. No difference is > observed at 1Gbps. > > Signed-off-by: Beniamino Galvani > --- [snip] > priv->dev->stats.tx_errors++; > @@ -2049,6 +2057,7 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, > struct net_device *dev) > skb_tx_timestamp(skb); > > priv->hw->dma->enable_dma_transmission(priv->ioaddr); > + netdev_sent_queue(dev, skb->len); You are introducing a potential use after free here in case tx_lock is eliminated one day and your TX reclaim logic kicks in and frees the freshly transmitted SKB, it would be safer to just cache skb->len in a local variable, and use it here. > > spin_unlock(&priv->tx_lock); > return NETDEV_TX_OK; -- Florian -- 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/1] perf list: Fix --raw-dump option
Hi Taesoo,
On Fri, Dec 26, 2014 at 11:29:33PM -0500, Taesoo Kim wrote:
> Currently, 'perf list --raw-dump' requires extra arguments
> (e.g., hw) to invoke, which breaks bash/zsh completion
> (perf-completion.sh).
>
> $ perf list --raw-dump
> Error: unknown option `raw-dump'
>
> usage: perf list [hw|sw|cache|tracepoint|pmu|event_glob]
>
> After,
>
> $ perf list --raw-dump
> cpu-cycles instructions cache-references cache-misses ...
>
> Signed-off-by: Taesoo Kim
Thanks for fixing this. Actually the --raw-dump option is intended to
support shell completion and not to be used directly. I didn't update
the completion script for a while so didn't notice it. It seems like
recent updates of the option parsing code broke this.
> ---
> tools/perf/builtin-list.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
> index 011195e..ec76bee 100644
> --- a/tools/perf/builtin-list.c
> +++ b/tools/perf/builtin-list.c
> @@ -16,14 +16,17 @@
> #include "util/pmu.h"
> #include "util/parse-options.h"
>
> +static bool raw_dump = false;
> +
> int cmd_list(int argc, const char **argv, const char *prefix __maybe_unused)
> {
> int i;
> const struct option list_options[] = {
> + OPT_BOOLEAN(0, "raw-dump", &raw_dump, "Dump raw events"),
> OPT_END()
> };
> const char * const list_usage[] = {
> - "perf list [hw|sw|cache|tracepoint|pmu|event_glob]",
> + "perf list [hw|sw|cache|tracepoint|pmu|event_glob|--raw-dump]",
> NULL
> };
So I'd like to keep the usage string as is and mark the option as
hidden - i.e. using set_option_flag(list_options, 0, "raw-dump",
PARSE_OPT_HIDDEN) before calling to parse_options().
With that,
Acked-by: Namhyung Kim
Thanks,
Namhyung
>
> @@ -32,6 +35,11 @@ int cmd_list(int argc, const char **argv, const char
> *prefix __maybe_unused)
>
> setup_pager();
>
> + if (raw_dump) {
> + print_events(NULL, true);
> + return 0;
> + }
> +
> if (argc == 0) {
> print_events(NULL, false);
> return 0;
> @@ -53,8 +61,6 @@ int cmd_list(int argc, const char **argv, const char
> *prefix __maybe_unused)
> print_hwcache_events(NULL, false);
> else if (strcmp(argv[i], "pmu") == 0)
> print_pmu_events(NULL, false);
> - else if (strcmp(argv[i], "--raw-dump") == 0)
> - print_events(NULL, true);
> else {
> char *sep = strchr(argv[i], ':'), *s;
> int sep_idx;
> --
> 2.1.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
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] usb: gadget: udc-core: call udc_stop() before gadget unbind
Hi Felipe, On 12/23/2014 07:31 PM, Felipe Balbi wrote: > On Tue, Dec 23, 2014 at 07:34:15AM +0100, Robert Baldyga wrote: >> On 12/22/2014 05:34 PM, Felipe Balbi wrote: >>> On Mon, Dec 15, 2014 at 11:05:22AM +0100, Robert Baldyga wrote: On 12/15/2014 06:13 AM, Peter Chen wrote: > On Fri, Dec 12, 2014 at 02:17:28PM +0100, Robert Baldyga wrote: >> As usb function drivers assumes that all usb request will be completed >> before function unbind call, we should supply such behavior. In some >> cases ep_disable() won't kill all request effectively, because some >> IN requests can be in running state. In such situation it's possible >> to have unbind function called before last request completion, which >> can cause problems. > > Doesn't the function's disable/unbind should call usb_ep_dequeue to make > sure the transfer has ended? USB function drivers like ECM or HID surely doesn't. It looks like there's assumption that all requests will be completed by UDC driver. >>> >>> that's a bug on those drivers :-) >> >> So we can't make assumptions that requests will be completed in >> ep_disable()? > > oh, no you can. I misread it. > Function ep_disable() should complete requests in hardware driver, but at least in DWC2 driver not all requests are completed at this stage >>> >>> and that's a bug on dwc2 :-) >> >> I have already found that out. Another UDC drivers simply kill all >> request without waiting for currently running, so I did the same in >> DWC2. Here is my patch: >> http://www.spinics.net/lists/linux-usb/msg118698.html > > should be in my pull request already. It looks like you applied wrong patch. I meant patch titled "drivers: usb: dwc2: remove 'force' parameter from kill_all_requests()" is the latest and complete fix. The patch you have applied named "usb: dwc2: gadget: kill requests with 'force' in s3c_hsotg_udc_stop()" do not solve problem completely without changes in udc-core, which we concluded are not acceptable. Sorry for the mess. I understand that titles of both patches are confusing similar. Best regards, Robert Baldyga -- 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/3] Dell Airplane Mode Switch driver
On Fri, Dec 26, 2014 at 5:55 AM, Gabriele Mazzotta
wrote:
> On Thursday 25 December 2014 21:11:05 Pali Rohár wrote:
>> I will try to recap all information which we have...
>>
>> *) We should not send wireless key press to userspace when BIOS
>> already handles wireless state (and enable/disable wifi):
>> http://www.spinics.net/lists/platform-driver-x86/msg05922.html
>>
>> *) some tested dell machines does not implement GRBT method (or
>> report constant value) which could return state of wireless
>> (enabled/disabled) -- e.g. Inspiron 7447
>>
>> *) dell-wireless driver is doing nothing on devices which have
>> wireless slider switch (except calling CRBT/ARBT methods)
>>
>> *) all tested machines emit key with keycode 240 (scancode is
>> probably 136 = 0x88) to userspace via i8042 bus/AT keyboard when
>> wireless button/slider is pressed/switched
>>
>> *) both drivers dell-wireless and dell-rbtn do not implement
>> setting soft rfkill state (or change wifi state)
>>
>> So in my opinion: if we decide to use driver for acpi DELLABCE
>> device we should use dell-rbnt for devices with hw slider switch
>> and dell-wireless for devices with fn button. I think it does not
>> make sense to use dell-wireless for devices with hw slider
>> because it do nothing and dell-rbtn for devices with fn key
>> button as GRBT does not working properly.
>
> Here the problem. We are determining which laptop has an hardware
> slider and which doesn't calling CRBT. If the returned value is 2
> or 3, then the laptop has an hardware slider. However, it cannot be
> assumed the opposite if the returned value is 0 or 1.
The spec defines as below:
1. When CRBT returns 0 or 1, a system has a toggle, ex. hotkey, radio button.
2. When CRBT returns 2 or 3, a system has a slider switch
The only difference of 0 and 1 (or 2 and 3) is the presence of a
wireless LED. However I believe this is defined according to
Microsoft's hardware requirement.
>
> See the acpidumps Alex uploaded. The Inspiron 3543 returns 0 when
> CRBT is called and so does the Inspiron 7447. However, the former
> doesn't have a working ARBT method and, if I'm not wrong, its BIOS
> doesn't handle radio devices. The BIOS of the latter can handle
> radio and has a working ARBT method to make it stop from doing that.
>
> Since we determine when the BIOS might not be able to control radio
> devices through CRBT and we can't say it for sure (in the example
> above, CRBT returned the same value), we make sure that the BIOS
> doesn't handle radio devices by calling ARBT. We can ensure this
> (e.g. Inspirong 7447), but we can't ensure the opposite (e.g.
> Inspiron 3453).
>
> If there was a way to determine which laptop really needs
> dell-wireless, calling ARBT wouldn't have been necessary, but that's
> not the case. Users can always blacklist the module if they know
> their laptop can work as expected without it, but we have to ensure
> that everything always works.
>
> This is what I understood by looking at the acpidumps, so I could
> be wrong.
>
I think ARBT acts as a switch for changing BIOS behaviours:
When ARBT is not called or is called with ARBT(0), BIOS's default
behaviour is to change wireless states by hardware pin. When ARBT(1)
is called by driver or userspace application (ex. required in Windows
8), wireless state is controlled by OS. Similar functions are defined
in ASUS ATK and HP WMI. Such implementation will provide maximum
capability for different OS with / without dedicate drivers.
The reality is never such wonderful; especially many systems are only
tested with Win8 + driver (some may tested with Win7 - and
acpi_osi=!Windows 2012 / 2013 will probably work). In this case, we
probably need to be more compatible with Windows 8 / 8.1.
>> And second note: Do we need some driver for acpi DELLABCE device?
>> Which problem is trying acpi DELLABCE device to solve? Is not
>> everything working fine without driver for DELLABCE device?
>
> As I wrote above, DELLABCE is for those systems whose BIOS doesn't
> handle radio devices and expects the OS do everything when Fn keys
> are pressed.
> (Well, it actually seems that something is done by the keyboard
> controller, but this is not certain yet)
>
>> My dell-rbtn approach is trying to export rfkill interface from
>> DELLABCE device and eliminate using i8042 hook function in smbios
>> dell-laptop driver.
>>
>> Alex, can you check if scancode of wireless change generated by
>> BIOS is on all machines same: 136 (0x88)? And is send by keyboard
>> controller (not acpi/wmi)?
>
> I can say that on my XPS13 the scancode is 0x88 and it is sent by
> the keyboard controller.
>
> Gabriele
Just before I check the scancode, I looked up the scancode table
(http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/translate.pdf)
and found 0x88 is already used - it is the "break" ("release" in Linux
term) code for "7" (the one above Y/U, not number pad). It can be
verified by "showkey -s": 0x08 for press and 0
RE: [RFC PATCH] f2fs: add extent cache base on rb-tree
Hi Jaegeuk, > -Original Message- > From: Jaegeuk Kim [mailto:jaeg...@kernel.org] > Sent: Thursday, December 25, 2014 4:35 PM > To: Chao Yu > Cc: 'Changman Lee'; linux-f2fs-de...@lists.sourceforge.net; > linux-kernel@vger.kernel.org > Subject: Re: [RFC PATCH] f2fs: add extent cache base on rb-tree > > Hi Chao, > > On Wed, Dec 24, 2014 at 04:01:16PM +0800, Chao Yu wrote: > > Hi Jaegeuk, > > > > > -Original Message- > > > From: Jaegeuk Kim [mailto:jaeg...@kernel.org] > > > Sent: Tuesday, December 23, 2014 3:36 PM > > > To: Chao Yu > > > Cc: 'Changman Lee'; linux-f2fs-de...@lists.sourceforge.net; > > > linux-kernel@vger.kernel.org > > > Subject: Re: [RFC PATCH] f2fs: add extent cache base on rb-tree > > > > > > Hi Chao, > > > > > > On Tue, Dec 23, 2014 at 11:01:39AM +0800, Chao Yu wrote: > > > > Hi Jaegeuk, > > > > > > > > > -Original Message- > > > > > From: Jaegeuk Kim [mailto:jaeg...@kernel.org] > > > > > Sent: Tuesday, December 23, 2014 7:16 AM > > > > > To: Chao Yu > > > > > Cc: 'Changman Lee'; linux-f2fs-de...@lists.sourceforge.net; > linux-kernel@vger.kernel.org > > > > > Subject: Re: [RFC PATCH] f2fs: add extent cache base on rb-tree > > > > > > > > > > Hi Chao, > > > > > > > > > > On Mon, Dec 22, 2014 at 03:10:30PM +0800, Chao Yu wrote: > > > > > > Hi Changman, > > > > > > > > > > > > > -Original Message- > > > > > > > From: Changman Lee [mailto:cm224@samsung.com] > > > > > > > Sent: Monday, December 22, 2014 10:03 AM > > > > > > > To: Chao Yu > > > > > > > Cc: Jaegeuk Kim; linux-f2fs-de...@lists.sourceforge.net; > linux-kernel@vger.kernel.org > > > > > > > Subject: Re: [RFC PATCH] f2fs: add extent cache base on rb-tree > > > > > > > > > > > > > > Hi Yu, > > > > > > > > > > > > > > Good approach. > > > > > > > > > > > > Thank you. :) > > > > > > > > > > > > > As you know, however, f2fs breaks extent itself due to COW. > > > > > > > > > > > > Yes, and sometimes f2fs use IPU when override writing, in this > > > > > > condition, > > > > > > by using this approach we can cache more contiguous mapping extent > > > > > > for better > > > > > > performance. > > > > > > > > > > Hmm. When f2fs faces with this case, there is no chance to make an > > > > > extent itself > > > > > at all. > > > > > > > > With new implementation of this patch f2fs will build extent cache when > > > > readpage/readpages. > > > > > > I don't understand your points exactly. :( > > > If there are no on-disk extents, it doesn't matter when the caches are > > > built. > > > Could you define what scenarios you're looking at? > > > > What I mean is that IPU will not split the exist extent in extent cache; and > > this exist extent cache was been built when we init cache with last > > accessed extent > > (the only on-disk extent) which was stored in inode, or be built when we > > invoke > > get_data_block in readpage/readpages in IPU mode. So there is a chance to > > make > > extent in this scenario. > > As long as I can understand your point, IPU can mitigate data fragmentation, > resulting in more extents, but current IPU policies except FORCE are activated > only when partition was already fragmented a lot such as high utilization or > SSR modes. That's why I said IPU is actually not helping extent caches. Yeah, I think in a real environment this point you descript is right. > > [snip] > > > > > IMO, node page cache belongs to system level cache, filesystem sub > > > > system can > > > > not control it completely, cached uptodate node page will be > > > > invalidated by > > > > using drop_caches from sysfs, or reclaimer of mm, result in more IO > > > > when we need > > > > these node page next time. > > > > > > Yes, that's exactly what I wanted. > > > > IMO, cost is expensive when we read node page again if these pages are > > invalidated > > by MM. In the worst case, we will read 3 ind-node blocks + 1 dnode block + > > 3 NAT blocks > > from disk for one blkaddr. > > My point is who should control this sort of caches. > At least, we should focus on the hit ratio, not the worst case comparison. > In the worst case, extent cache has more overhead than node page cache alone. Yes, so this RFC version extent cache should be improved. > > > > > > > > > > New extent cache belongs to filesystem level cache, it is completely > > > > controlled > > > > by filesystem itself. What we can profit is: on the one hand, it is > > > > used as > > > > first level cache above the node page cache, which can also increase > > > > the cache > > > > hit ratio. > > > > > > I don't think so. The hit ratio depends on the cache policy. The node page > > > cache is managed globally by kernel in LRU manner, so I think this can > > > show > > > affordable hit ratio. > > > > As I test, in this scenario we can have higher ratio hit in new extent cache > > than original extent cache: > > 1.write a large file > > 2.write randomly in this file > > 3.drop cache through drop_caches entry (or reclaim by MM) >
Re: [PATCH] bcma: fix three coding style issues, more than 80 characters per line
Rafał Miłecki writes: > On 27 December 2014 at 20:24, Oscar Forner Martinez > wrote: >> Three lines with more than 80 characters per line have been split in several >> lines. >> >> Signed-off-by: Oscar Forner Martinez > > Acked-by: Rafał Miłecki > > Kalle: will you pick this patch? Most likely yes, but let's wait first for John's opinion about how to handle bcma patches. -- Kalle Valo -- 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 3/3] Staging: comedi: fix space and 80 char coding style issue
On Mon, Dec 29, 2014 at 03:14:45AM +0530, jitendra kumar khasdev wrote:
> This is a patch to the s626.c file that fixes up spcae and maximum
> character limit warning found by the checkpatch.pl tool
you are doing two different kind of changes in this patch. it should be in two
different patches. One patch should do only one type of change.
thanks
sudip
>
> Signed-off-by: Jitendra Kumar Khasdev
> ---
> drivers/staging/comedi/drivers/s626.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/comedi/drivers/s626.c
> b/drivers/staging/comedi/drivers/s626.c
> index 14932c5..77f715b 100644
> --- a/drivers/staging/comedi/drivers/s626.c
> +++ b/drivers/staging/comedi/drivers/s626.c
> @@ -118,7 +118,7 @@ static void s626_mc_enable(struct comedi_device *dev,
> static void s626_mc_disable(struct comedi_device *dev,
> unsigned int cmd, unsigned int reg)
> {
> - writel(cmd << 16 , dev->mmio + reg);
> + writel(cmd << 16, dev->mmio + reg);
> mmiowb();
> }
>
> @@ -2534,7 +2534,8 @@ static int s626_initialize(struct comedi_device *dev)
> for (i = 0; i < 2; i++) {
> writel(S626_I2C_CLKSEL, dev->mmio + S626_P_I2CSTAT);
> s626_mc_enable(dev, S626_MC2_UPLD_IIC, S626_P_MC2);
> - ret = comedi_timeout(dev, NULL, NULL, s626_i2c_handshake_eoc,
> 0);
> + ret = comedi_timeout(dev, NULL, NULL, s626_i2c_handshake_eoc,
> + 0);
> if (ret)
> return ret;
> }
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
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 18/37] perf tools: Remove thread when map groups initialization failed
On Sat, Dec 27, 2014 at 05:45:56PM -0700, David Ahern wrote:
> On 12/24/14 12:15 AM, Namhyung Kim wrote:
> >Otherwise it'll break the machine->threads tree.
> >
> >Signed-off-by: Namhyung Kim
> >---
> > tools/perf/util/machine.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> >diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
> >index 031bace39fdc..beae6e8fe789 100644
> >--- a/tools/perf/util/machine.c
> >+++ b/tools/perf/util/machine.c
> >@@ -411,6 +411,7 @@ static struct thread *__machine__findnew_thread(struct
> >machine *machine,
> > * leader and that would screwed the rb tree.
> > */
> > if (thread__init_map_groups(th, machine)) {
> >+rb_erase(&th->rb_node, &machine->threads);
> > thread__delete(th);
> > return NULL;
> > }
> >
>
> Can you move the thread__init_map_groups() before the thread is added to the
> rbtree? If no, you need to delay setting 'machine->last_match = th'
> otherwise it references a deleted thread.
You're right - I'll move the setting after the thread__init_map_groups().
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: line6: remove spaces before commas.
On Sun, Dec 28, 2014 at 09:30:44PM +0100, Jonas Lundqvist wrote: > Hi Jeremiah, > > On 12/28/2014 04:44 PM, Jeremiah Mahler wrote: > > Jonas, > > > > On Sun, Dec 28, 2014 at 02:26:46PM +0100, Jonas Lundqvist wrote: > >> Fixed three errors in pcm.h found by checkpatch.pl. > > > > What type of errors did you fix? > > These errors: > drivers/staging/line6/pcm.h:148: ERROR: space prohibited before that ',' > (ctx:WxE) > drivers/staging/line6/pcm.h:155: ERROR: space prohibited before that ',' > (ctx:WxE) > drivers/staging/line6/pcm.h:162: ERROR: space prohibited before that ',' > (ctx:WxE) I am sure Jeremiah Mahler actually wanted to tell you that you should include that information in the commit log. We always mention what kind of error was fixed. thanks sudip > > > BR > Jonas > -- 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/
[LKP] [xfs] dbe1b5ca263: +6.5% will-it-scale.per_thread_ops
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
commit dbe1b5ca26396b6c61d711c8ac4de13ebb02e9f6 ("xfs: Make xfs_vn_rename
compliant with renameat2() syscall")
testbox/testcase/testparams: lkp-nex05/will-it-scale/performance-pwrite1
v3.19-rc1 dbe1b5ca26396b6c61d711c8ac
--
%stddev %change %stddev
\ |\
1131870 ± 0% +6.5%1205531 ± 0% will-it-scale.per_thread_ops
1209729 ± 0% +5.8%1280184 ± 0% will-it-scale.per_process_ops
0.54 ± 0% -3.1% 0.53 ± 1% will-it-scale.scalability
1400 ± 30%+174.5% 3842 ± 34% sched_debug.cpu#36.nr_switches
810 ± 33%+154.2% 2060 ± 25% sched_debug.cpu#36.ttwu_count
163 ± 41% +96.6%320 ± 42% sched_debug.cpu#2.ttwu_local
242 ± 38% +71.4%416 ± 19% slabinfo.blkdev_queue.active_objs
137 ± 28% +99.3%274 ± 22% sched_debug.cpu#26.ttwu_local
29 ± 44%+116.0% 63 ± 28%
sched_debug.cfs_rq[50]:/.tg_load_contrib
1296 ± 34% +41.5% 1835 ± 19% sched_debug.cpu#63.ttwu_local
405 ± 30% -42.3%234 ± 15% sched_debug.cpu#56.sched_goidle
314 ± 27% +43.6%452 ± 11% slabinfo.blkdev_queue.num_objs
980 ± 28% -37.7%611 ± 13% sched_debug.cpu#56.nr_switches
684 ± 25% +40.5%962 ± 20% sched_debug.cpu#10.ttwu_count
1.03 ± 2% -38.8% 0.63 ± 7%
perf-profile.cpu-cycles.current_kernel_time.file_update_time.__generic_file_write_iter.generic_file_write_iter.new_sync_write
838 ± 25% -33.1%560 ± 14% sched_debug.cpu#60.nr_switches
4870 ± 19% +25.8% 6127 ± 14% sched_debug.cpu#63.nr_switches
1443 ± 10% +39.9% 2019 ± 23% sched_debug.cpu#2.sched_count
39 ± 20% +55.1% 61 ± 16%
latency_stats.max.call_rwsem_down_write_failed.SyS_mprotect.system_call_fastpath
336 ± 33% -37.8%209 ± 12% sched_debug.cpu#60.sched_goidle
2.27 ± 12% -33.6% 1.51 ± 2%
perf-profile.cpu-cycles.rw_verify_area.vfs_write.sys_pwrite64.system_call_fastpath.__libc_pwrite
394 ± 19% -31.5%270 ± 13% sched_debug.cpu#52.sched_goidle
986 ± 19% -25.0%740 ± 11% sched_debug.cpu#52.nr_switches
2.25 ± 4% -28.4% 1.61 ± 6%
perf-profile.cpu-cycles.security_file_permission.rw_verify_area.vfs_write.sys_pwrite64.system_call_fastpath
257 ± 15% +52.9%394 ± 28% sched_debug.cpu#10.ttwu_local
1.24 ± 10% -26.7% 0.91 ± 8%
perf-profile.cpu-cycles.selinux_file_permission.security_file_permission.rw_verify_area.vfs_write.sys_pwrite64
1.12 ± 6% -27.7% 0.81 ± 8%
perf-profile.cpu-cycles.rw_verify_area.vfs_write.sys_pwrite64.system_call_fastpath.__libc_pwrite64
3385 ± 10% +8.9% 3687 ± 8% sched_debug.cpu#39.curr->pid
4.01 ± 0% +27.4% 5.11 ± 1%
perf-profile.cpu-cycles.file_update_time.__generic_file_write_iter.generic_file_write_iter.new_sync_write.vfs_write
1.05 ± 2% -23.8% 0.80 ± 5%
perf-profile.cpu-cycles.iov_iter_fault_in_readable.__generic_file_write_iter.generic_file_write_iter.new_sync_write.vfs_write
0.83 ± 3% +24.7% 1.03 ± 1%
perf-profile.cpu-cycles.current_fs_time.file_update_time.__generic_file_write_iter.generic_file_write_iter.new_sync_write
0.88 ± 2% +15.2% 1.02 ± 2%
perf-profile.cpu-cycles.__sb_end_write.vfs_write.sys_pwrite64.system_call_fastpath.__libc_pwrite64
0.99 ± 1% +14.5% 1.14 ± 1%
perf-profile.cpu-cycles.system_call.__libc_pwrite
2.60 ± 2% +11.7% 2.91 ± 0%
perf-profile.cpu-cycles.__srcu_read_lock.fsnotify.vfs_write.sys_pwrite64.system_call_fastpath
3.56 ± 6% +12.4% 4.00 ± 4%
perf-profile.cpu-cycles.unlock_page.shmem_write_end.generic_perform_write.__generic_file_write_iter.generic_file_write_iter
252 ± 0% +7.8%272 ± 1% time.user_time
lkp-nex05: Nehalem-EX
Memory: 192G
will-it-scale.per_process_ops
1.4e+06 ++--O--O-+
1.38e+06 O+ O O |
| O |
1.36e+06 ++ O|
1.34e+06 ++ |
||
1.32e+06 ++ O |
1.3e+06 ++O O O |
1.28e+06 ++ O O O O O
[PATCH] x86/hw-breakpoints: eliminate a compiler warning for hw_breakpoint.c
There is a warning message when we compile the linux-next tree.
arch/x86/kernel/hw_breakpoint.c: In function ‘arch_validate_hwbkpt_settings’:
arch/x86/kernel/hw_breakpoint.c:329:20: warning: ‘align’ may be used
uninitialized in this function [-Wuninitialized]
This patch aims to eliminate the above compiler warning.
Signed-off-by: Chen Yucong
---
arch/x86/kernel/hw_breakpoint.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/hw_breakpoint.c b/arch/x86/kernel/hw_breakpoint.c
index 7114ba2..302eab3 100644
--- a/arch/x86/kernel/hw_breakpoint.c
+++ b/arch/x86/kernel/hw_breakpoint.c
@@ -293,7 +293,7 @@ static int arch_build_bp_info(struct perf_event *bp)
int arch_validate_hwbkpt_settings(struct perf_event *bp)
{
struct arch_hw_breakpoint *info = counter_arch_bp(bp);
- unsigned int align;
+ unsigned int align = ~0x0U;
int ret;
--
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] staging: ft1000: ft1000-usb: ft1000_hw.c: Fix a potential memory leak.
On Sat, Dec 27, 2014 at 07:45:07PM +0100, Rickard Strandqvist wrote:
> Avoid allocate memory if we will exit the function.
>
> Was found by using a static code analysis program called cppcheck.
>
> Signed-off-by: Rickard Strandqvist
> ---
> drivers/staging/ft1000/ft1000-usb/ft1000_hw.c |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/ft1000/ft1000-usb/ft1000_hw.c
> b/drivers/staging/ft1000/ft1000-usb/ft1000_hw.c
> index 2e13e7b..72b8f03 100644
> --- a/drivers/staging/ft1000/ft1000-usb/ft1000_hw.c
> +++ b/drivers/staging/ft1000/ft1000-usb/ft1000_hw.c
> @@ -331,15 +331,15 @@ int card_send_command(struct ft1000_usb *ft1000dev,
> void *ptempbuffer,
>
> DEBUG("card_send_command: enter card_send_command... size=%d\n", size);
this is not applying to next-20141226. your tree is not a current one. This
DEBUG line was changed by patch "b5d8204d00fa3bcd1f3b4b060fb90675d00baee0"
thanks
sudip
>
> + ret = ft1000_read_register(ft1000dev, &temp, FT1000_REG_DOORBELL);
> + if (ret)
> + return ret;
> +
> commandbuf = kmalloc(size + 2, GFP_KERNEL);
> if (!commandbuf)
> return -ENOMEM;
> memcpy((void *)commandbuf + 2, (void *)ptempbuffer, size);
>
> - ret = ft1000_read_register(ft1000dev, &temp, FT1000_REG_DOORBELL);
> - if (ret)
> - return ret;
> -
> if (temp & 0x0100)
> usleep_range(900, 1100);
>
> --
> 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/
--
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 RFC v6 03/21] of: Add vendor prefix for Truly Semiconductors Limited
Signed-off-by: Liu Ying --- v5->v6: * None. v4->v5: * None. v3->v4: * None. v2->v3: * None. v1->v2: * None. Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index f46adb2..0e67bad 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -158,6 +158,7 @@ tlm Trusted Logic Mobility toradexToradex AG toshibaToshiba Corporation toumaz Toumaz +truly Truly Semiconductors Limited usiUniversal Scientific Industrial Co., Ltd. v3 V3 Semiconductor variscite Variscite Ltd. -- 2.1.0 -- 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 RFC v6 02/21] of: Add vendor prefix for Himax Technologies Inc.
Signed-off-by: Liu Ying --- v5->v6: * None. v4->v5: * None. v3->v4: * Fix an ordering issue to address Stefan Wahren's comment. v2->v3: * None. v1->v2: * None. Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 78efebb..f46adb2 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -67,6 +67,7 @@ gumstix Gumstix, Inc. gw Gateworks Corporation hannstar HannStar Display Corporation haoyu Haoyu Microelectronic Co. Ltd. +himax Himax Technologies, Inc. hisilicon Hisilicon Limited. hitHitachi Ltd. honeywell Honeywell -- 2.1.0 -- 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 RFC v6 05/21] ARM: imx6q: clk: Add the video_27m clock
This patch supports the video_27m clock which is a fixed factor
clock of the pll3_pfd1_540m clock.
Signed-off-by: Liu Ying
---
v5->v6:
* None.
v4->v5:
* None.
v3->v4:
* None.
v2->v3:
* None.
v1->v2:
* None.
arch/arm/mach-imx/clk-imx6q.c | 1 +
include/dt-bindings/clock/imx6qdl-clock.h | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 4e79da7..9470df3 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -246,6 +246,7 @@ static void __init imx6q_clocks_init(struct device_node
*ccm_node)
clk[IMX6QDL_CLK_PLL3_60M] = imx_clk_fixed_factor("pll3_60m",
"pll3_usb_otg", 1, 8);
clk[IMX6QDL_CLK_TWD] = imx_clk_fixed_factor("twd", "arm",
1, 2);
clk[IMX6QDL_CLK_GPT_3M]= imx_clk_fixed_factor("gpt_3m","osc",
1, 8);
+ clk[IMX6QDL_CLK_VIDEO_27M] = imx_clk_fixed_factor("video_27m",
"pll3_pfd1_540m", 1, 20);
if (cpu_is_imx6dl()) {
clk[IMX6QDL_CLK_GPU2D_AXI] = imx_clk_fixed_factor("gpu2d_axi",
"mmdc_ch0_axi_podf", 1, 1);
clk[IMX6QDL_CLK_GPU3D_AXI] = imx_clk_fixed_factor("gpu3d_axi",
"mmdc_ch0_axi_podf", 1, 1);
diff --git a/include/dt-bindings/clock/imx6qdl-clock.h
b/include/dt-bindings/clock/imx6qdl-clock.h
index b690cdb..25625bf 100644
--- a/include/dt-bindings/clock/imx6qdl-clock.h
+++ b/include/dt-bindings/clock/imx6qdl-clock.h
@@ -248,6 +248,7 @@
#define IMX6QDL_PLL6_BYPASS235
#define IMX6QDL_PLL7_BYPASS236
#define IMX6QDL_CLK_GPT_3M 237
-#define IMX6QDL_CLK_END238
+#define IMX6QDL_CLK_VIDEO_27M 238
+#define IMX6QDL_CLK_END239
#endif /* __DT_BINDINGS_CLOCK_IMX6QDL_H */
--
2.1.0
--
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 RFC v6 07/21] ARM: imx6q: clk: Change hsi_tx clock to be a shared clock gate
The CG8 field of the CCM CCGR3 register is named as 'mipi_core_cfg'
clock, according to the i.MX6q/sdl reference manuals. This clock is
actually the gate for several clocks, including the hsi_tx_sel clock's
output and the video_27m clock's output. So, this patch changes the
hsi_tx clock to be a shared clock gate.
Suggested-by: Philipp Zabel
Signed-off-by: Liu Ying
---
v5->v6:
* None.
v4->v5:
* None.
v3->v4:
* None.
v2->v3:
* Newly introduced in v3.
arch/arm/mach-imx/clk-imx6q.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index f19472a..080d5b7 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -119,6 +119,7 @@ static unsigned int share_count_asrc;
static unsigned int share_count_ssi1;
static unsigned int share_count_ssi2;
static unsigned int share_count_ssi3;
+static unsigned int share_count_mipi_core_cfg;
static void __init imx6q_clocks_init(struct device_node *ccm_node)
{
@@ -416,7 +417,7 @@ static void __init imx6q_clocks_init(struct device_node
*ccm_node)
clk[IMX6QDL_CLK_LDB_DI0] = imx_clk_gate2("ldb_di0",
"ldb_di0_podf", base + 0x74, 12);
clk[IMX6QDL_CLK_LDB_DI1] = imx_clk_gate2("ldb_di1",
"ldb_di1_podf", base + 0x74, 14);
clk[IMX6QDL_CLK_IPU2_DI1] = imx_clk_gate2("ipu2_di1",
"ipu2_di1_sel", base + 0x74, 10);
- clk[IMX6QDL_CLK_HSI_TX] = imx_clk_gate2("hsi_tx",
"hsi_tx_podf", base + 0x74, 16);
+ clk[IMX6QDL_CLK_HSI_TX] = imx_clk_gate2_shared("hsi_tx",
"hsi_tx_podf", base + 0x74, 16, &share_count_mipi_core_cfg);
if (cpu_is_imx6dl())
/*
* The multiplexer and divider of the imx6q clock gpu2d get
--
2.1.0
--
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 RFC v6 09/21] ARM: dts: imx6qdl: Move existing MIPI DSI ports into a new 'ports' node
The MIPI DSI node contains some ports which represent possible DRM CRTCs
it can connect with. Each port has a 'reg' property embedded. This
property will be wrongly interpretted by the MIPI DSI bus driver, because
the driver will take each subnode which contains a 'reg' property as a
DSI peripheral device. This patch moves the existing MIPI DSI ports into
a new 'ports' node so that the MIPI DSI bus driver may distinguish its
DSI peripheral device(s) from the existing ports.
Acked-by: Philipp Zabel
Signed-off-by: Liu Ying
---
v5->v6:
* None.
v4->v5:
* None.
v3->v4:
* None.
v2->v3:
* Add Philipp's Ack.
v1->v2:
* Newly added, as suggested by Thierry Reding.
arch/arm/boot/dts/imx6q.dtsi | 20 +++-
arch/arm/boot/dts/imx6qdl.dtsi | 23 ++-
2 files changed, 25 insertions(+), 18 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index e9f3646..9c0990b 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -292,19 +292,21 @@
};
&mipi_dsi {
- port@2 {
- reg = <2>;
+ ports {
+ port@2 {
+ reg = <2>;
- mipi_mux_2: endpoint {
- remote-endpoint = <&ipu2_di0_mipi>;
+ mipi_mux_2: endpoint {
+ remote-endpoint = <&ipu2_di0_mipi>;
+ };
};
- };
- port@3 {
- reg = <3>;
+ port@3 {
+ reg = <3>;
- mipi_mux_3: endpoint {
- remote-endpoint = <&ipu2_di1_mipi>;
+ mipi_mux_3: endpoint {
+ remote-endpoint = <&ipu2_di1_mipi>;
+ };
};
};
};
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 9596ed5..96bf2a0 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1009,19 +1009,24 @@
reg = <0x021e 0x4000>;
status = "disabled";
- port@0 {
- reg = <0>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
- mipi_mux_0: endpoint {
- remote-endpoint =
<&ipu1_di0_mipi>;
+ mipi_mux_0: endpoint {
+ remote-endpoint =
<&ipu1_di0_mipi>;
+ };
};
- };
- port@1 {
- reg = <1>;
+ port@1 {
+ reg = <1>;
- mipi_mux_1: endpoint {
- remote-endpoint =
<&ipu1_di1_mipi>;
+ mipi_mux_1: endpoint {
+ remote-endpoint =
<&ipu1_di1_mipi>;
+ };
};
};
};
--
2.1.0
--
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] sched/core: remove check of p->sched_class
Search all usage of p->sched_class in sched/core.c, no one check it
before use, so it seems that every task must belong to one sched_class.
Signed-off-by: Yao Dongdong
---
kernel/sched/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index b5797b7..bdab49b 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4740,7 +4740,7 @@ static struct rq *move_queued_task(struct task_struct *p,
int new_cpu)
void do_set_cpus_allowed(struct task_struct *p, const struct cpumask *new_mask)
{
- if (p->sched_class && p->sched_class->set_cpus_allowed)
+ if (p->sched_class->set_cpus_allowed)
p->sched_class->set_cpus_allowed(p, new_mask);
cpumask_copy(&p->cpus_allowed, new_mask);
--
2.1.0
--
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 RFC v6 17/21] ARM: dtsi: imx6qdl: Add support for MIPI DSI host controller
This patch adds support for MIPI DSI host controller.
Signed-off-by: Liu Ying
---
v5->v6:
* None.
v3->v4:
* None.
v2->v3:
* As suggested by Phillip Zabel, change the clocks and the clock-names
properties to use the pllref and core_cfg clocks only.
v1->v2:
* None.
arch/arm/boot/dts/imx6qdl.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 96bf2a0..7b1c313 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1006,7 +1006,13 @@
mipi_dsi: mipi@021e {
#address-cells = <1>;
#size-cells = <0>;
+ compatible = "fsl,imx6q-mipi-dsi";
reg = <0x021e 0x4000>;
+ interrupts = <0 102 IRQ_TYPE_LEVEL_HIGH>;
+ gpr = <&gpr>;
+ clocks = <&clks IMX6QDL_CLK_MIPI_CORE_CFG>,
+<&clks IMX6QDL_CLK_MIPI_CORE_CFG>;
+ clock-names = "pllref", "core_cfg";
status = "disabled";
ports {
--
2.1.0
--
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 RFC v6 12/21] drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver
This patch adds Synopsys DesignWare MIPI DSI host controller driver support. Currently, the driver supports the burst with sync pulses mode only. Signed-off-by: Liu Ying --- v5->v6: * Make the checkpatch.pl script be happier. v4->v5: * Remove 'dsi->panel = NULL;' in dw_mipi_dsi_host_detach() to address Andrzej Hajda's comment. v3->v4: * Move the relevant dt-bindings to a separate patch to address Stefan Wahren's comment. v2->v3: * Newly introduced in v3 to address Andy Yan's comment. This is based on the i.MX MIPI DSI driver in v2. To make the Synopsys DesignWare MIPI DSI host controller driver less platform-dependant, this patch places it at the drm/bridge directory as a DRM bridge driver. drivers/gpu/drm/bridge/Kconfig | 5 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/dw_mipi_dsi.c | 996 +++ include/drm/bridge/dw_mipi_dsi.h | 27 + 4 files changed, 1029 insertions(+) create mode 100644 drivers/gpu/drm/bridge/dw_mipi_dsi.c create mode 100644 include/drm/bridge/dw_mipi_dsi.h diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 884923f..8180477 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -1,3 +1,8 @@ +config DRM_DW_MIPI_DSI + bool "Synopsys DesignWare MIPI DSI host controller bridge" + depends on DRM + select DRM_KMS_HELPER + config DRM_PTN3460 tristate "PTN3460 DP/LVDS bridge" depends on DRM diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index b4733e1..b326ad5 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -1,3 +1,4 @@ ccflags-y := -Iinclude/drm +obj-$(CONFIG_DRM_DW_MIPI_DSI) += dw_mipi_dsi.o obj-$(CONFIG_DRM_PTN3460) += ptn3460.o diff --git a/drivers/gpu/drm/bridge/dw_mipi_dsi.c b/drivers/gpu/drm/bridge/dw_mipi_dsi.c new file mode 100644 index 000..2b54d44 --- /dev/null +++ b/drivers/gpu/drm/bridge/dw_mipi_dsi.c @@ -0,0 +1,996 @@ +/* + * Synopsys DesignWare(DW) MIPI DSI Host Controller + * + * Copyright (C) 2011-2014 Freescale Semiconductor, Inc. + * + * 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. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#define DSI_VERSION0x00 + +#define DSI_PWR_UP 0x04 +#define RESET 0 +#define POWERUPBIT(0) + +#define DSI_CLKMGR_CFG 0x08 +#define TO_CLK_DIVIDSION(div) (((div) & 0xff) << 8) +#define TX_ESC_CLK_DIVIDSION(div) (((div) & 0xff) << 0) + +#define DSI_DPI_CFG0x0c +#define EN18_LOOSELY BIT(10) +#define COLORM_ACTIVE_LOW BIT(9) +#define SHUTD_ACTIVE_LOW BIT(8) +#define HSYNC_ACTIVE_LOW BIT(7) +#define VSYNC_ACTIVE_LOW BIT(6) +#define DATAEN_ACTIVE_LOW BIT(5) +#define DPI_COLOR_CODING_16BIT_1 (0x0 << 2) +#define DPI_COLOR_CODING_16BIT_2 (0x1 << 2) +#define DPI_COLOR_CODING_16BIT_3 (0x2 << 2) +#define DPI_COLOR_CODING_18BIT_1 (0x3 << 2) +#define DPI_COLOR_CODING_18BIT_2 (0x4 << 2) +#define DPI_COLOR_CODING_24BIT (0x5 << 2) +#define DPI_VID(vid) (((vid) & 0x3) << 0) + +#define DSI_DBI_CFG0x10 +#define DSI_DBIS_CMDSIZE 0x14 + +#define DSI_PCKHDL_CFG 0x18 +#define GEN_VID_RX(vid)(((vid) & 0x3) << 5) +#define EN_CRC_RX BIT(4) +#define EN_ECC_RX BIT(3) +#define EN_BTA BIT(2) +#define EN_EOTN_RX BIT(1) +#define EN_EOTP_TX BIT(0) + +#define DSI_VID_MODE_CFG 0x1c +#define FRAME_BTA_ACK BIT(11) +#define EN_NULL_PKTBIT(10) +#define EN_NULL_PKT_MASK BIT(10) +#define EN_MULTI_PKT BIT(9) +#define ENABLE_LOW_POWER (0x3f << 3) +#define ENABLE_LOW_POWER_MASK (0x3f << 3) +#define VID_MODE_TYPE_NONBURST_SYNC_PULSES (0x0 << 1) +#define VID_MODE_TYPE_NONBURST_SYNC_EVENTS (0x1 << 1) +#define VID_MODE_TYPE_BURST_SYNC_PULSES(0x3 << 1) +#define VID_MODE_TYPE_MASK (0x3 << 1) +#define ENABLE_VIDEO_MODE BIT(0) +#define DISABLE_VIDEO_MODE 0 +#define ENABLE_VIDEO_MODE_MA
[PATCH RFC v6 16/21] drm: panel: Add support for Himax HX8369A MIPI DSI panel
This patch adds support for Himax HX8369A MIPI DSI panel.
Signed-off-by: Liu Ying
---
v5->v6:
* Make the checkpatch.pl script be happier.
* Do not set the dsi channel number to be zero in probe(), because the MIPI DSI
bus driver would set it.
v4->v5:
* Address Andrzej Hajda's comments.
* Get the bs-gpios property instead of the bs[3:0]-gpios properties.
* Implement error propagation for panel register configurations.
* Other minor changes to improve the code quality.
v3->v4:
* Move the relevant dt-bindings to a separate patch to address Stefan
Wahren's comment.
v2->v3:
* Sort the included header files alphabetically.
v1->v2:
* Address almost all comments from Thierry Reding.
* Remove several DT properties as they can be implied by the compatible string.
* Add the HIMAX/himax prefixes to the driver's Kconfig name and driver name.
* Move the driver's Makefile entry place to sort the entries alphabetically.
* Reuse several standard DCS functions instead of inventing wheels.
* Move the panel resetting and power logics to the driver probe/remove stages.
This may simplify panel prepare/unprepare hooks. The power consumption should
not change a lot at DPMS since the panel enters sleep mode at that time.
* Add the module author.
* Other minor changes, such as coding style issues.
drivers/gpu/drm/panel/Kconfig | 5 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-himax-hx8369a.c | 614
3 files changed, 620 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-himax-hx8369a.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 024e98e..81b0bf0 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -16,6 +16,11 @@ config DRM_PANEL_SIMPLE
that it can be automatically turned off when the panel goes into a
low power state.
+config DRM_PANEL_HIMAX_HX8369A
+ tristate "Himax HX8369A panel"
+ depends on OF
+ select DRM_MIPI_DSI
+
config DRM_PANEL_LD9040
tristate "LD9040 RGB/SPI panel"
depends on OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 4b2a043..d5dbe06 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
+obj-$(CONFIG_DRM_PANEL_HIMAX_HX8369A) += panel-himax-hx8369a.o
obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
diff --git a/drivers/gpu/drm/panel/panel-himax-hx8369a.c
b/drivers/gpu/drm/panel/panel-himax-hx8369a.c
new file mode 100644
index 000..eee36a7
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-himax-hx8369a.c
@@ -0,0 +1,614 @@
+/*
+ * Himax HX8369A panel driver.
+ *
+ * Copyright (C) 2011-2014 Freescale Semiconductor, Inc.
+ *
+ * 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.
+ *
+ * This driver is based on Samsung s6e8aa0 panel driver.
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#define WRDISBV0x51
+#define WRCTRLD0x53
+#define WRCABC 0x55
+#define SETPOWER 0xb1
+#define SETDISP0xb2
+#define SETCYC 0xb4
+#define SETVCOM0xb6
+#define SETEXTC0xb9
+#define SETMIPI0xba
+#define SETPANEL 0xcc
+#define SETGIP 0xd5
+#define SETGAMMA 0xe0
+
+#define HX8369A_MIN_BRIGHTNESS 0x00
+#define HX8369A_MAX_BRIGHTNESS 0xff
+
+enum hx8369a_mpu_interface {
+ HX8369A_DBI_TYPE_A_8BIT,
+ HX8369A_DBI_TYPE_A_9BIT,
+ HX8369A_DBI_TYPE_A_16BIT,
+ HX8369A_DBI_TYPE_A_18BIT,
+ HX8369A_DBI_TYPE_B_8BIT,
+ HX8369A_DBI_TYPE_B_9BIT,
+ HX8369A_DBI_TYPE_B_16BIT,
+ HX8369A_DBI_TYPE_B_18BIT,
+ HX8369A_DSI_CMD_MODE,
+ HX8369A_DBI_TYPE_B_24BIT,
+ HX8369A_DSI_VIDEO_MODE,
+ HX8369A_MDDI,
+ HX8369A_DPI_DBI_TYPE_C_OPT1,
+ HX8369A_DPI_DBI_TYPE_C_OPT2,
+ HX8369A_DPI_DBI_TYPE_C_OPT3
+};
+
+enum hx8369a_resolution {
+ HX8369A_RES_480_864,
+ HX8369A_RES_480_854,
+ HX8369A_RES_480_800,
+ HX8369A_RES_480_640,
+ HX8369A_RES_360_640,
+ HX8369A_RES_480_720,
+};
+
+struct hx8369a_panel_desc {
+ const struct drm_display_mode *mode;
+
+ /* ms */
+ unsigned int power_on_delay;
+ unsigned int reset_delay;
+
+ unsigned int dsi_lanes;
+};
+
+struct hx8369a {
+ struct device *dev;
+ struct drm_panel panel;
+
+ const struct hx8369a_panel_desc *pd;
+
+ struct regulator_bulk_data supplies[5];
+ struct gpio_desc *reset_gpio;
+ struct gpio_desc *bs_g
[PATCH RFC v6 18/21] ARM: dts: imx6qdl-sabresd: Add support for TRULY TFT480800-16-E MIPI DSI panel
The TRULY TFT480800-16-E panel is driven by the Himax HX8369A driver IC.
The driver IC supports several display/control interface modes, including
the MIPI DSI video mode and command mode.
Signed-off-by: Liu Ying
---
v5->v6:
* None.
v4->v5:
* Replace the bs[3:0]-gpios properties with the bs-gpios property.
This addresses Andrzej Hajda's comment.
v3->v4:
* None.
v2->v3:
* None.
v1->v2:
* To address Thierry Reding's comments, remove several unnecessary
properties as they can be implied by the compatible string.
* Fix the compatible string.
* Remove the display-timings node from the panel node as it can be
implied by the compatible string as well.
* Remove the status property as it is unneeded.
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index baf2f00..4e3a666 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -482,6 +482,13 @@
MX6QDL_PAD_SD4_DAT7__SD4_DATA7 0x17059
>;
};
+
+ pinctrl_mipi_panel: mipipanelgrp {
+ fsl,pins = <
+ MX6QDL_PAD_NANDF_CS0__GPIO6_IO11 0x1b0b0
+ MX6QDL_PAD_NANDF_CS1__GPIO6_IO14 0x1b0b0
+ >;
+ };
};
gpio_leds {
@@ -518,6 +525,19 @@
};
};
+&mipi_dsi {
+ status = "okay";
+
+ panel {
+ compatible = "truly,tft480800-16-e-dsi";
+ reg = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mipi_panel>;
+ reset-gpios = <&gpio6 11 GPIO_ACTIVE_LOW>;
+ bs-gpios = <0>, <0>, <&gpio6 14 GPIO_ACTIVE_HIGH>, <0>;
+ };
+};
+
&pcie {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pcie>;
--
2.1.0
--
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 RFC v6 15/21] Documentation: dt-bindings: Add bindings for Himax HX8369A DRM panel driver
This patch adds device tree bindings for Himax HX8369A DRM panel driver.
Signed-off-by: Liu Ying
---
v5->v6:
* None.
v4->v5:
* Merge the bs[3:0]-gpios properties into one property - bs-gpios.
This addresses Andrzej Hajda's comment.
v3->v4:
* Newly introduced in v4. This is separated from the relevant driver patch
in v3 to address Stefan Wahren's comment.
.../devicetree/bindings/panel/himax,hx8369a.txt| 39 ++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/panel/himax,hx8369a.txt
diff --git a/Documentation/devicetree/bindings/panel/himax,hx8369a.txt
b/Documentation/devicetree/bindings/panel/himax,hx8369a.txt
new file mode 100644
index 000..3a44b70
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/himax,hx8369a.txt
@@ -0,0 +1,39 @@
+Himax HX8369A WVGA 16.7M color TFT single chip driver with internal GRAM
+
+Himax HX8369A is a WVGA resolution driving controller.
+It is designed to provide a single chip solution that combines a source
+driver and power supply circuits to drive a TFT dot matrix LCD with
+480RGBx864 dots at the maximum.
+
+The HX8369A supports several interface modes, including MPU MIPI DBI Type
+A/B mode, MIPI DPI/DBI Type C mode, MIPI DSI video mode, MIPI DSI command
+mode and MDDI mode. The interface mode is selected by the external hardware
+pins BS[3:0].
+
+Currently, only the MIPI DSI video mode is supported.
+
+Required properties:
+ - compatible: should be a panel's compatible string
+ - reg: the virtual channel number of a DSI peripheral, as described in [1]
+ - reset-gpios: a GPIO spec for the reset pin, as described in [2]
+
+Optional properties:
+ - vdd1-supply: I/O and interface power supply
+ - vdd2-supply: analog power supply
+ - vdd3-supply: logic power supply
+ - dsi-vcc-supply: DSI and MDDI power supply
+ - vpp-supply: OTP programming voltage
+ - bs-gpios: a GPIO spec for the pins BS[3:0], as described in [2]
+
+[1] Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
+[2] Documentation/devicetree/bindings/gpio/gpio.txt
+
+Example:
+ panel {
+ compatible = "truly,tft480800-16-e-dsi";
+ reg = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mipi_panel>;
+ reset-gpios = <&gpio6 11 GPIO_ACTIVE_LOW>;
+ bs-gpios = <0>, <0>, <&gpio6 14 GPIO_ACTIVE_HIGH>, <0>;
+ };
--
2.1.0
--
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 RFC v6 14/21] drm: imx: Support Synopsys DesignWare MIPI DSI host controller
This patch adds support for Synopsys DesignWare MIPI DSI host controller
which is embedded in the i.MX6q/sdl SoCs.
Signed-off-by: Liu Ying
---
v5->v6:
* Make the checkpatch.pl script be happier.
v4->v5:
* None.
v3->v4:
* Move the relevant dt-bindings to a separate patch to address Stefan
Wahren's comment.
v2->v3:
* To address Andy Yan's comments, move the common Synopsys DesignWare MIPI DSI
host controller logic into it's drm/bridge driver and leave the i.MX specific
logic only.
v1->v2:
* Address almost all comments from Thierry Reding and Russell.
* Update the DT documentation to remove the display-timings node in the panel
node.
* Update the DT documentation to state that the nodes which represent the
possible
DRM CRTCs the controller may connect with should be placed in the node
"ports".
* Remove the flag 'enabled' from the struct imx_mipi_dsi.
* Move the format_to_bpp() function in v1 to the common DRM MIPI DSI driver.
* Improve the way we wait for check status for DPHY and command packet
transfer.
* Improve the DPMS support for the encoder.
* Split the functions of ->host_attach() and ->mode_valid() clearly as
suggested by
Thierry Reding.
* Improve the logics in imx_mipi_dsi_dcs_long_write().
* Enable/disable the pllref_clk and pllref_gate_clk at the component
binding/unbinding
stages to help remove the flag 'enabled'.
* Update the module license to be "GPL".
* Other minor changes, such as coding style issues and macro naming issues.
drivers/gpu/drm/imx/Kconfig | 7 ++
drivers/gpu/drm/imx/Makefile | 1 +
drivers/gpu/drm/imx/dw_mipi_dsi-imx.c | 230 ++
3 files changed, 238 insertions(+)
create mode 100644 drivers/gpu/drm/imx/dw_mipi_dsi-imx.c
diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig
index 82fb758..c576f6b 100644
--- a/drivers/gpu/drm/imx/Kconfig
+++ b/drivers/gpu/drm/imx/Kconfig
@@ -51,3 +51,10 @@ config DRM_IMX_HDMI
depends on DRM_IMX
help
Choose this if you want to use HDMI on i.MX6.
+
+config DRM_IMX_MIPI_DSI
+ tristate "Freescale i.MX DRM MIPI DSI"
+ select DRM_DW_MIPI_DSI
+ depends on DRM_IMX
+ help
+ Choose this if you want to use MIPI DSI on i.MX6.
diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile
index 582c438..f0dc278 100644
--- a/drivers/gpu/drm/imx/Makefile
+++ b/drivers/gpu/drm/imx/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o
imx-ipuv3-crtc-objs := ipuv3-crtc.o ipuv3-plane.o
obj-$(CONFIG_DRM_IMX_IPUV3)+= imx-ipuv3-crtc.o
obj-$(CONFIG_DRM_IMX_HDMI) += imx-hdmi.o
+obj-$(CONFIG_DRM_IMX_MIPI_DSI) += dw_mipi_dsi-imx.o
diff --git a/drivers/gpu/drm/imx/dw_mipi_dsi-imx.c
b/drivers/gpu/drm/imx/dw_mipi_dsi-imx.c
new file mode 100644
index 000..b2c96e2
--- /dev/null
+++ b/drivers/gpu/drm/imx/dw_mipi_dsi-imx.c
@@ -0,0 +1,230 @@
+/*
+ * i.MX drm driver - MIPI DSI Host Controller
+ *
+ * Copyright (C) 2011-2014 Freescale Semiconductor, Inc.
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "imx-drm.h"
+
+#define DRIVER_NAME"imx-mipi-dsi"
+
+struct imx_mipi_dsi {
+ struct drm_encoder encoder;
+ struct device *dev;
+ struct regmap *regmap;
+};
+
+static inline struct imx_mipi_dsi *enc_to_dsi(struct drm_encoder *enc)
+{
+ return container_of(enc, struct imx_mipi_dsi, encoder);
+}
+
+static void imx_mipi_dsi_set_ipu_di_mux(struct imx_mipi_dsi *dsi, int ipu_di)
+{
+ regmap_update_bits(dsi->regmap, IOMUXC_GPR3,
+ IMX6Q_GPR3_MIPI_MUX_CTL_MASK,
+ ipu_di << IMX6Q_GPR3_MIPI_MUX_CTL_SHIFT);
+}
+
+static struct drm_encoder_funcs imx_mipi_dsi_encoder_funcs = {
+ .destroy = imx_drm_encoder_destroy,
+};
+
+static bool imx_mipi_dsi_encoder_mode_fixup(struct drm_encoder *encoder,
+ const struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+ return true;
+}
+
+static void imx_mipi_dsi_encoder_prepare(struct drm_encoder *encoder)
+{
+ u32 encoder_pix_fmt, interface_pix_fmt;
+
+ encoder_pix_fmt = dw_mipi_dsi_get_encoder_pixel_format(encoder);
+
+ switch (encoder_pix_fmt) {
+ case MIPI_DSI_FMT_RGB888:
+ interface_pix_fmt = V4L2_PIX_FMT_RGB24;
+ break;
+
[PATCH RFC v6 20/21] ARM: imx_v6_v7_defconfig: Add support for MIPI DSI host controller
This patch adds support for MIPI DSI host controller. The new imx_v6_v7_defconfig is generated in this way: * make ARCH=arm imx_v6_v7_defconfig * make ARCH=arm menuconfig and manually choose to build in the MIPI DSI host controller driver * make ARCH=arm savedefconfig * cp defconfig arch/arm/configs/imx_v6_v7_defconfig Signed-off-by: Liu Ying --- v5->v6: * None. v4->v5: * None. v3->v4: * None. v2->v3: * None. v1->v2: * None. arch/arm/configs/imx_v6_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig index 0dbd0c3..3e0e589 100644 --- a/arch/arm/configs/imx_v6_v7_defconfig +++ b/arch/arm/configs/imx_v6_v7_defconfig @@ -199,6 +199,7 @@ CONFIG_DRM_IMX_TVE=y CONFIG_DRM_IMX_LDB=y CONFIG_DRM_IMX_IPUV3=y CONFIG_DRM_IMX_HDMI=y +CONFIG_DRM_IMX_MIPI_DSI=y CONFIG_LCD_CLASS_DEVICE=y CONFIG_LCD_L4F00242T03=y CONFIG_LCD_PLATFORM=y -- 2.1.0 -- 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 RFC v6 19/21] ARM: imx_v6_v7_defconfig: Cleanup for imx drm being moved out of staging
The new imx_v6_v7_defconfig is generated in this way: * make ARCH=arm imx_v6_v7_defconfig * make ARCH=arm savedefconfig * cp defconfig arch/arm/configs/imx_v6_v7_defconfig Signed-off-by: Liu Ying --- v5->v6: * None. v4->v5: * None. v3->v4: * None. v2->v3: * None. v1->v2: * None. arch/arm/configs/imx_v6_v7_defconfig | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig index 6790f1b..0dbd0c3 100644 --- a/arch/arm/configs/imx_v6_v7_defconfig +++ b/arch/arm/configs/imx_v6_v7_defconfig @@ -192,7 +192,13 @@ CONFIG_SOC_CAMERA_OV2640=y CONFIG_IMX_IPUV3_CORE=y CONFIG_DRM=y CONFIG_DRM_PANEL_SIMPLE=y -CONFIG_BACKLIGHT_LCD_SUPPORT=y +CONFIG_DRM_IMX=y +CONFIG_DRM_IMX_FB_HELPER=y +CONFIG_DRM_IMX_PARALLEL_DISPLAY=y +CONFIG_DRM_IMX_TVE=y +CONFIG_DRM_IMX_LDB=y +CONFIG_DRM_IMX_IPUV3=y +CONFIG_DRM_IMX_HDMI=y CONFIG_LCD_CLASS_DEVICE=y CONFIG_LCD_L4F00242T03=y CONFIG_LCD_PLATFORM=y @@ -249,13 +255,6 @@ CONFIG_IMX_SDMA=y CONFIG_MXS_DMA=y CONFIG_FSL_EDMA=y CONFIG_STAGING=y -CONFIG_DRM_IMX=y -CONFIG_DRM_IMX_FB_HELPER=y -CONFIG_DRM_IMX_PARALLEL_DISPLAY=y -CONFIG_DRM_IMX_TVE=y -CONFIG_DRM_IMX_LDB=y -CONFIG_DRM_IMX_IPUV3=y -CONFIG_DRM_IMX_HDMI=y # CONFIG_IOMMU_SUPPORT is not set CONFIG_PWM=y CONFIG_PWM_IMX=y -- 2.1.0 -- 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 RFC v6 21/21] ARM: imx_v6_v7_defconfig: Add support for Himax HX8369A panel
This patch adds support for Himax HX8369A panel. The new imx_v6_v7_defconfig is generated in this way: * make ARCH=arm imx_v6_v7_defconfig * make ARCH=arm menuconfig and manually choose to build in the Himax HX8369A panel driver * make ARCH=arm savedefconfig * cp defconfig arch/arm/configs/imx_v6_v7_defconfig Signed-off-by: Liu Ying --- v5->v6: * None. v4->v5: * None. v3->v4: * None. v2->v3: * None. v1->v2: * Add the HIMAX prefix in the Kconfig name. arch/arm/configs/imx_v6_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig index 3e0e589..27db91b 100644 --- a/arch/arm/configs/imx_v6_v7_defconfig +++ b/arch/arm/configs/imx_v6_v7_defconfig @@ -192,6 +192,7 @@ CONFIG_SOC_CAMERA_OV2640=y CONFIG_IMX_IPUV3_CORE=y CONFIG_DRM=y CONFIG_DRM_PANEL_SIMPLE=y +CONFIG_DRM_PANEL_HIMAX_HX8369A=y CONFIG_DRM_IMX=y CONFIG_DRM_IMX_FB_HELPER=y CONFIG_DRM_IMX_PARALLEL_DISPLAY=y -- 2.1.0 -- 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 RFC v6 01/21] clk: divider: Correct parent clk round rate if no bestdiv is normally found
If no best divider is normally found, we will try to use the maximum divider.
We should not set the parent clock rate to be 1Hz by force for being rounded.
Instead, we should take the maximum divider as a base and calculate a correct
parent clock rate for being rounded.
Signed-off-by: Liu Ying
---
v5->v6:
* None.
v4->v5:
* None.
v3->v4:
* None.
v2->v3:
* None.
v1->v2:
* None.
drivers/clk/clk-divider.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index c0a842b..f641d4b 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -311,7 +311,8 @@ static int clk_divider_bestdiv(struct clk_hw *hw, unsigned
long rate,
if (!bestdiv) {
bestdiv = _get_maxdiv(divider);
- *best_parent_rate = __clk_round_rate(__clk_get_parent(hw->clk),
1);
+ *best_parent_rate = __clk_round_rate(__clk_get_parent(hw->clk),
+ MULT_ROUND_UP(rate, bestdiv));
}
return bestdiv;
--
2.1.0
--
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 RFC v6 13/21] Documentation: dt-bindings: Add bindings for i.MX specific Synopsys DW MIPI DSI driver
This patch adds device tree bindings for i.MX specific Synopsys DW MIPI DSI
driver.
Signed-off-by: Liu Ying
---
v5->v6:
* Add the #address-cells and #size-cells properties in the example 'ports'
node.
* Remove the useless pllref_gate clock from the required clocks, clock-names
property.
v4->v5:
* None.
v3->v4:
* Newly introduced in v4. This is separated from the relevant driver patch
in v3 to address Stefan Wahren's comment.
.../devicetree/bindings/drm/imx/mipi_dsi.txt | 78 ++
1 file changed, 78 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/imx/mipi_dsi.txt
diff --git a/Documentation/devicetree/bindings/drm/imx/mipi_dsi.txt
b/Documentation/devicetree/bindings/drm/imx/mipi_dsi.txt
new file mode 100644
index 000..75a7766
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/imx/mipi_dsi.txt
@@ -0,0 +1,78 @@
+i.MX specific Device-Tree bindings for Synopsys DesignWare MIPI DSI host
controller
+
+MIPI DSI host controller
+
+
+The MIPI DSI host controller is a Synopsys DesignWare IP.
+The common device tree documentation for this controller can be found
+at [1].
+
+Required properties:
+ - #address-cells: Should be <1>.
+ - #size-cells: Should be <0>.
+ - compatible: The compatible string should be "fsl,imx6q-mipi-dsi"
+ for i.MX6q/sdl SoCs.
+ - reg: Physical base address of the controller and length of memory
+ mapped region.
+ - interrupts: The controller's interrupt number to the CPU(s).
+ - gpr: Should be <&gpr>.
+ The phandle points to the iomuxc-gpr region containing the
+ multiplexer control register for the controller.
+ - clocks, clock-names: Phandles to the controller pllref and core_cfg clocks,
+ as described in [2] and [3].
+
+Required sub-nodes:
+ - ports: This node may contain up to four port nodes with endpoint
+ definitions as defined in [4], corresponding to the four inputs to
+ the controller multiplexer.
+ - A node to represent a DSI peripheral as described in [5].
+
+[1] Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt.
+[2] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[3] Documentation/devicetree/bindings/clock/imx6q-clock.txt
+[4] Documentation/devicetree/bindings/media/video-interfaces.txt
+[5] Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
+
+example:
+ gpr: iomuxc-gpr@020e {
+ /* ... */
+ };
+
+ mipi_dsi: mipi@021e {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,imx6q-mipi-dsi";
+ reg = <0x021e 0x4000>;
+ interrupts = <0 102 IRQ_TYPE_LEVEL_HIGH>;
+ gpr = <&gpr>;
+ clocks = <&clks IMX6QDL_CLK_MIPI_CORE_CFG>,
+<&clks IMX6QDL_CLK_MIPI_CORE_CFG>;
+ clock-names = "pllref", "core_cfg";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ mipi_mux_0: endpoint {
+ remote-endpoint = <&ipu1_di0_mipi>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ mipi_mux_1: endpoint {
+ remote-endpoint = <&ipu1_di1_mipi>;
+ };
+ };
+ };
+
+ panel {
+ compatible = "truly,tft480800-16-e-dsi";
+ reg = <0>;
+ /* ... */
+ };
+ };
--
2.1.0
--
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 RFC v6 08/21] ARM: imx6q: clk: Add support for mipi_core_cfg clock as a shared clock gate
The CG8 field of the CCM CCGR3 register is named as 'mipi_core_cfg' clock,
according to the i.MX6q/sdl reference manuals. This clock is actually the
gate for several clocks, including the hsi_tx_sel clock's output and the
video_27m clock's output. The MIPI DSI host controller embedded in the
i.MX6q/sdl SoCs uses the video_27m clock to generate PLL reference clock and
MIPI core configuration clock. In order to gate/ungate the two MIPI DSI
host controller relevant clocks, this patch adds the mipi_core_cfg clock as
a shared clock gate.
Suggested-by: Philipp Zabel
Signed-off-by: Liu Ying
---
v5->v6:
* Add two spaces in the clock driver to eliminate two errors reported by
the checkpatch.pl script.
v4->v5:
* None.
v3->v4:
* None.
v2->v3:
* Newly introduced in v3.
arch/arm/mach-imx/clk-imx6q.c | 1 +
include/dt-bindings/clock/imx6qdl-clock.h | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 080d5b7..0f4d07c 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -418,6 +418,7 @@ static void __init imx6q_clocks_init(struct device_node
*ccm_node)
clk[IMX6QDL_CLK_LDB_DI1] = imx_clk_gate2("ldb_di1",
"ldb_di1_podf", base + 0x74, 14);
clk[IMX6QDL_CLK_IPU2_DI1] = imx_clk_gate2("ipu2_di1",
"ipu2_di1_sel", base + 0x74, 10);
clk[IMX6QDL_CLK_HSI_TX] = imx_clk_gate2_shared("hsi_tx",
"hsi_tx_podf", base + 0x74, 16, &share_count_mipi_core_cfg);
+ clk[IMX6QDL_CLK_MIPI_CORE_CFG] = imx_clk_gate2_shared("mipi_core_cfg",
"video_27m", base + 0x74, 16, &share_count_mipi_core_cfg);
if (cpu_is_imx6dl())
/*
* The multiplexer and divider of the imx6q clock gpu2d get
diff --git a/include/dt-bindings/clock/imx6qdl-clock.h
b/include/dt-bindings/clock/imx6qdl-clock.h
index 25625bf..dbc828c 100644
--- a/include/dt-bindings/clock/imx6qdl-clock.h
+++ b/include/dt-bindings/clock/imx6qdl-clock.h
@@ -249,6 +249,7 @@
#define IMX6QDL_PLL7_BYPASS236
#define IMX6QDL_CLK_GPT_3M 237
#define IMX6QDL_CLK_VIDEO_27M 238
-#define IMX6QDL_CLK_END239
+#define IMX6QDL_CLK_MIPI_CORE_CFG 239
+#define IMX6QDL_CLK_END240
#endif /* __DT_BINDINGS_CLOCK_IMX6QDL_H */
--
2.1.0
--
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 RFC v6 10/21] drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format
Signed-off-by: Liu Ying
---
v5->v6:
* Address the over 80 characters in one line warning reported by the
checkpatch.pl script.
v4->v5:
* None.
v3->v4:
* None.
v2->v3:
* None.
v1->v2:
* Thierry Reding suggested that the mipi_dsi_pixel_format_to_bpp() function
could be placed at the common DRM MIPI DSI driver.
This patch is newly added.
include/drm/drm_mipi_dsi.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index f1d8d0d..3662021 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -163,6 +163,20 @@ static inline struct mipi_dsi_device
*to_mipi_dsi_device(struct device *dev)
return container_of(dev, struct mipi_dsi_device, dev);
}
+static inline int mipi_dsi_pixel_format_to_bpp(enum mipi_dsi_pixel_format fmt)
+{
+ switch (fmt) {
+ case MIPI_DSI_FMT_RGB888:
+ case MIPI_DSI_FMT_RGB666:
+ return 24;
+ case MIPI_DSI_FMT_RGB666_PACKED:
+ return 18;
+ case MIPI_DSI_FMT_RGB565:
+ return 16;
+ }
+ return -EINVAL;
+}
+
struct mipi_dsi_device *of_find_mipi_dsi_device_by_node(struct device_node
*np);
int mipi_dsi_attach(struct mipi_dsi_device *dsi);
int mipi_dsi_detach(struct mipi_dsi_device *dsi);
--
2.1.0
--
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 RFC v6 06/21] ARM: imx6q: clk: Change hdmi_isfr clock's parent to be video_27m clock
According to the table 33-1 in the i.MX6Q reference manual, the hdmi_isfr
clock's parent should be the video_27m clock. The i.MX6DL reference manual
has the same statement. This patch changes the hdmi_isfr clock's parent
from the pll3_pfd1_540m clock to the video_27m clock.
Suggested-by: Philipp Zabel
Signed-off-by: Liu Ying
---
v5->v6:
* None.
v4->v5:
* None.
v3->v4:
* None.
v2->v3:
* Newly introduced in v3.
arch/arm/mach-imx/clk-imx6q.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 9470df3..f19472a 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -401,7 +401,7 @@ static void __init imx6q_clocks_init(struct device_node
*ccm_node)
clk[IMX6QDL_CLK_GPU2D_CORE] = imx_clk_gate2("gpu2d_core",
"gpu2d_core_podf", base + 0x6c, 24);
clk[IMX6QDL_CLK_GPU3D_CORE] = imx_clk_gate2("gpu3d_core",
"gpu3d_core_podf", base + 0x6c, 26);
clk[IMX6QDL_CLK_HDMI_IAHB]= imx_clk_gate2("hdmi_iahb", "ahb",
base + 0x70, 0);
- clk[IMX6QDL_CLK_HDMI_ISFR]= imx_clk_gate2("hdmi_isfr",
"pll3_pfd1_540m",base + 0x70, 4);
+ clk[IMX6QDL_CLK_HDMI_ISFR]= imx_clk_gate2("hdmi_isfr",
"video_27m", base + 0x70, 4);
clk[IMX6QDL_CLK_I2C1] = imx_clk_gate2("i2c1",
"ipg_per", base + 0x70, 6);
clk[IMX6QDL_CLK_I2C2] = imx_clk_gate2("i2c2",
"ipg_per", base + 0x70, 8);
clk[IMX6QDL_CLK_I2C3] = imx_clk_gate2("i2c3",
"ipg_per", base + 0x70, 10);
--
2.1.0
--
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 RFC v6 04/21] ARM: imx6q: Add GPR3 MIPI muxing control register field shift bits definition
This patch adds a macro to define the GPR3 MIPI muxing control register field shift bits. Signed-off-by: Liu Ying --- v5->v6: * None. v4->v5: * None. v3->v4: * None. v2->v3: * None. v1->v2: * None. include/linux/mfd/syscon/imx6q-iomuxc-gpr.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h b/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h index ff44374..3b0bed4 100644 --- a/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h +++ b/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h @@ -207,6 +207,7 @@ #define IMX6Q_GPR3_LVDS0_MUX_CTL_IPU1_DI1 (0x1 << 6) #define IMX6Q_GPR3_LVDS0_MUX_CTL_IPU2_DI0 (0x2 << 6) #define IMX6Q_GPR3_LVDS0_MUX_CTL_IPU2_DI1 (0x3 << 6) +#define IMX6Q_GPR3_MIPI_MUX_CTL_SHIFT 4 #define IMX6Q_GPR3_MIPI_MUX_CTL_MASK (0x3 << 4) #define IMX6Q_GPR3_MIPI_MUX_CTL_IPU1_DI0 (0x0 << 4) #define IMX6Q_GPR3_MIPI_MUX_CTL_IPU1_DI1 (0x1 << 4) -- 2.1.0 -- 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 RFC v6 11/21] Documentation: dt-bindings: Add bindings for Synopsys DW MIPI DSI DRM bridge driver
This patch adds device tree bindings for Synopsys DesignWare MIPI DSI
host controller DRM bridge driver.
Signed-off-by: Liu Ying
---
v5->v6:
* Add the #address-cells and #size-cells properties in the example 'ports'
node.
* Remove the useless input-port properties from the example port@0 and port@1
nodes.
v4->v5:
* None.
v3->v4:
* Newly introduced in v4. This is separated from the relevant driver patch
in v3 to address Stefan Wahren's comment.
.../devicetree/bindings/drm/bridge/dw_mipi_dsi.txt | 73 ++
1 file changed, 73 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt
diff --git a/Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt
b/Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt
new file mode 100644
index 000..f88a8d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt
@@ -0,0 +1,73 @@
+Device-Tree bindings for Synopsys DesignWare MIPI DSI host controller
+
+The controller is a digital core that implements all protocol functions
+defined in the MIPI DSI specification, providing an interface between
+the system and the MIPI DPHY, and allowing communication with a MIPI DSI
+compliant display.
+
+Required properties:
+ - #address-cells: Should be <1>.
+ - #size-cells: Should be <0>.
+ - compatible: The compatible string should be "fsl,imx6q-mipi-dsi" for
+ i.MX6q/sdl SoCs. For other SoCs, please refer to their specific
+ device tree binding documentations.
+ - reg: Represent the physical address range of the controller.
+ - interrupts: Represent the controller's interrupt to the CPU(s).
+ - clocks, clock-names: Phandles to the controller pll reference and
+ core configuration clocks, as described in [1].
+
+For more required properties, please refer to relevant device tree binding
+documentations which describe the controller embedded in specific SoCs.
+
+Required sub-nodes:
+ - A node to represent a DSI peripheral as described in [2].
+
+For more required sub-nodes, please refer to relevant device tree binding
+documentations which describe the controller embedded in specific SoCs.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
+
+example:
+ gpr: iomuxc-gpr@020e {
+ /* ... */
+ };
+
+ mipi_dsi: mipi@021e {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,imx6q-mipi-dsi";
+ reg = <0x021e 0x4000>;
+ interrupts = <0 102 IRQ_TYPE_LEVEL_HIGH>;
+ gpr = <&gpr>;
+ clocks = <&clks IMX6QDL_CLK_MIPI_CORE_CFG>,
+<&clks IMX6QDL_CLK_MIPI_CORE_CFG>;
+ clock-names = "pllref", "core_cfg";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ mipi_mux_0: endpoint {
+ remote-endpoint = <&ipu1_di0_mipi>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ mipi_mux_1: endpoint {
+ remote-endpoint = <&ipu1_di1_mipi>;
+ };
+ };
+ };
+
+ panel {
+ compatible = "truly,tft480800-16-e-dsi";
+ reg = <0>;
+ /* ... */
+ };
+ };
--
2.1.0
--
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 RFC v6 00/21] Add support for i.MX MIPI DSI DRM driver
Hi, This version does some minor changes to improve the code quality. The checkpatch.pl script is happier now on this version. For detail change log, please find them in each standalone patch. The i.MX MIPI DSI is a Synopsys DesignWare MIPI DSI host controller IP. This series adds support for a Synopsys DesignWare MIPI DSI host controller DRM bridge driver and a i.MX MIPI DSI specific DRM driver. Currently, the MIPI DSI drivers only support the burst with sync pulse mode. This series also includes a DRM panel driver for the Truly TFT480800-16-E panel which is driven by the Himax HX8369A driver IC. The driver IC data sheet could be found at [1]. As mentioned by the data sheet, the driver IC supports several interface modes. Currently, the DRM panel driver only supports the MIPI DSI video mode. New interface modes could be added later(perhaps, just like the way the DRM simple panel driver supports both MIPI DSI interface panels and simple(parallel) interface panels). The MIPI DSI feature is tested on i.MX6Q SabreSD board and i.MX6DL SabreSD board. The MIPI DSI display could be enabled directly on i.MX6Q SabreSD board after applying this series, because the 26.4MHz pixel clock the panel requires could be derived from the IPU HSP clock(264MHz) with an integer divider. On i.MX6DL SabreSD board, we need to manually disable the LVDS and HDMI displays in the device tree blob, since the i.MX6DL IPU HSP clock is 198MHz at present, which makes the pixel clock share the PLL5 video clock source with the LVDS and HDMI, thus, the panel cannot get the pixel clock rate it wants. Patch 01/21 is needed to get a precise pixel clock rate(26.4MHz) from the PLL5 video clock. If we don't have this patch, the pixel clock rate is about 20MHz, which causes a horitonal shift on the display image. This series can be applied on the drm-next branch. [1] http://www.allshore.com/pdf/Himax_HX8369-A.pdf Liu Ying (21): clk: divider: Correct parent clk round rate if no bestdiv is normally found of: Add vendor prefix for Himax Technologies Inc. of: Add vendor prefix for Truly Semiconductors Limited ARM: imx6q: Add GPR3 MIPI muxing control register field shift bits definition ARM: imx6q: clk: Add the video_27m clock ARM: imx6q: clk: Change hdmi_isfr clock's parent to be video_27m clock ARM: imx6q: clk: Change hsi_tx clock to be a shared clock gate ARM: imx6q: clk: Add support for mipi_core_cfg clock as a shared clock gate ARM: dts: imx6qdl: Move existing MIPI DSI ports into a new 'ports' node drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format Documentation: dt-bindings: Add bindings for Synopsys DW MIPI DSI DRM bridge driver drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver Documentation: dt-bindings: Add bindings for i.MX specific Synopsys DW MIPI DSI driver drm: imx: Support Synopsys DesignWare MIPI DSI host controller Documentation: dt-bindings: Add bindings for Himax HX8369A DRM panel driver drm: panel: Add support for Himax HX8369A MIPI DSI panel ARM: dtsi: imx6qdl: Add support for MIPI DSI host controller ARM: dts: imx6qdl-sabresd: Add support for TRULY TFT480800-16-E MIPI DSI panel ARM: imx_v6_v7_defconfig: Cleanup for imx drm being moved out of staging ARM: imx_v6_v7_defconfig: Add support for MIPI DSI host controller ARM: imx_v6_v7_defconfig: Add support for Himax HX8369A panel .../devicetree/bindings/drm/bridge/dw_mipi_dsi.txt | 73 ++ .../devicetree/bindings/drm/imx/mipi_dsi.txt | 78 ++ .../devicetree/bindings/panel/himax,hx8369a.txt| 39 + .../devicetree/bindings/vendor-prefixes.txt| 2 + arch/arm/boot/dts/imx6q.dtsi | 20 +- arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 20 + arch/arm/boot/dts/imx6qdl.dtsi | 29 +- arch/arm/configs/imx_v6_v7_defconfig | 17 +- arch/arm/mach-imx/clk-imx6q.c | 7 +- drivers/clk/clk-divider.c | 3 +- drivers/gpu/drm/bridge/Kconfig | 5 + drivers/gpu/drm/bridge/Makefile| 1 + drivers/gpu/drm/bridge/dw_mipi_dsi.c | 996 + drivers/gpu/drm/imx/Kconfig| 7 + drivers/gpu/drm/imx/Makefile | 1 + drivers/gpu/drm/imx/dw_mipi_dsi-imx.c | 230 + drivers/gpu/drm/panel/Kconfig | 5 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-himax-hx8369a.c| 614 + include/drm/bridge/dw_mipi_dsi.h | 27 + include/drm/drm_mipi_dsi.h | 14 + include/dt-bindings/clock/imx6qdl-clock.h | 4 +- include/linux/mfd/syscon/imx6q-iomuxc-gpr.h| 1 + 23 files changed, 2164 insertions(+), 30 deletions(-) create mode 100644 Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi
Re: [PATCH] staging: rtl8188eu: rtw_mlme.c: fix sparse warning
On 12/28/2014 11:47 PM, Serguey Parkhomovsky wrote: Fixes the following sparse warning for rtw_mlme.c: drivers/staging/rtl8188eu/core/rtw_mlme.c:810:9: warning: context imbalance in 'rtw_free_assoc_resources' - different lock contexts for basic block Signed-off-by: Serguey Parkhomovsky --- drivers/staging/rtl8188eu/core/rtw_mlme.c | 37 --- 1 file changed, 24 insertions(+), 13 deletions(-) Are these many changes needed just because Sparse is not smart enough to understand that the following does not really have a context imbalance: if (lock_scanned_queue) spin_lock_bh(&(pmlmepriv->scanned_queue.lock)); . . if (lock_scanned_queue) spin_unlock_bh(&pmlmepriv->scanned_queue.lock); Nothing in the middle touches lock_scanned_queue, thus if the spin lock and unlock operations will be paired. That is all that is important. The fact that some tool objects to this construct means that the tool is broken, not the code. In my mind, Sparse warnings/errors/checks are in place to alert you to a possible problem. If they point to white space issues, then you fix them. If they point to lines that are too long, then you see if you can shorten them without harming the readability. In any case, judgement should be used before blindly trying to silence the warning. For those reasons, NACK. Larry -- 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] Thermal: introduce INT3406 thermal driver
On 12/23/2014 09:26 AM, Aaron Lu wrote: > On 12/22/2014 05:53 PM, Lee Jones wrote: >> On Mon, 22 Dec 2014, Zhang Rui wrote: >> >>> On Thu, 2014-12-11 at 16:38 +0800, Aaron Lu wrote: INT3406 ACPI device object resembles an ACPI video output device, but its _BCM is said to be deprecated and should not be used. So we will make use of the raw interface to do the actual cooling. Due to this, the backlight core has some modifications. Also, to re-use some of the ACPI video module's code, one function has been exported. Signed-off-by: Aaron Lu >>> >>> Jingoo and Lee, >>> >>> are you okay with the changes in drivers/video/backlight/backlight.c and >>> include/linux/backlight.h? >> >> NB: Jingoo still needs to review the crux of the patch. >> --- v6: Fix an issue that wrongly set error path return value as reported by Olof Johansson. drivers/acpi/video.c | 77 drivers/thermal/Kconfig | 26 +-- drivers/thermal/int340x_thermal/Kconfig | 41 drivers/thermal/int340x_thermal/Makefile | 1 + drivers/thermal/int340x_thermal/int3406_thermal.c | 229 ++ drivers/video/backlight/backlight.c | 44 +++-- include/acpi/video.h | 20 ++ include/linux/backlight.h | 2 + 8 files changed, 366 insertions(+), 74 deletions(-) create mode 100644 drivers/thermal/int340x_thermal/Kconfig create mode 100644 drivers/thermal/int340x_thermal/int3406_thermal.c >> >> I gather by the message at the top that you're looking for an Ack so >> this can be routed through another subsystem. Not going to happen. >> >> So you're on v6 already and a) no one has mentioned that introducing a >> new driver AND making core framework changes (in a different subsystem >> to boot) in one patch is bad and b) this is the first time you've >> Cc'ed the maintainers of the aforementioned subsystem? >> >> Moving forward you should split this patch into component parts and >> resend -- only this time ensure you Cc all maintainers in the first >> instance, rather than as as afterthought. > > OK, thanks for the suggestion. > >> -config INT340X_THERMAL - tristate "ACPI INT340X thermal drivers" - depends on X86 && ACPI - select THERMAL_GOV_USER_SPACE - select ACPI_THERMAL_REL - select ACPI_FAN >> >> This patch also relies on backlight as well, no? > > Yes it does, will add it in next revision. My fault. INT340X_THERMAL does not rely on backlight, INT3406 does. Since I have marked INT3406 depends on ACPI_VIDEO, which depends on BACKLIGHT, so we are good here. Thanks, Aaron -- 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 3/3] cma: add functions to get region pages counters
On 12/27/2014 10:18 AM, SeongJae Park wrote: Hello, How about 'CMA Region' rather than 'CMARegion'? Sure. -- Best regards, Safonov Dmitry. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: rtl8188eu: rtw_mlme.c: fix sparse warning
Fixes the following sparse warning for rtw_mlme.c:
drivers/staging/rtl8188eu/core/rtw_mlme.c:810:9: warning: context imbalance in
'rtw_free_assoc_resources' - different lock contexts for basic block
Signed-off-by: Serguey Parkhomovsky
---
drivers/staging/rtl8188eu/core/rtw_mlme.c | 37 ---
1 file changed, 24 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index d4632da..a47717a 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -755,12 +755,30 @@ static void free_scanqueue(struct mlme_priv *pmlmepriv)
spin_unlock_bh(&scan_queue->lock);
}
+static void rtw_free_current_network(struct adapter *adapter)
+{
+ struct wlan_network *pwlan = NULL;
+ struct mlme_priv *pmlmepriv = &adapter->mlmepriv;
+ struct wlan_network *tgt_network = &pmlmepriv->cur_network;
+
+ pwlan = rtw_find_network(&pmlmepriv->scanned_queue,
+tgt_network->network.MacAddress);
+ if (pwlan)
+ pwlan->fixed = false;
+ else
+ RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_,
+ ("rtw_free_assoc_resources:pwlan==NULL\n\n"));
+
+ if (check_fwstate(pmlmepriv, WIFI_ADHOC_MASTER_STATE) &&
+(adapter->stapriv.asoc_sta_count == 1))
+ rtw_free_network_nolock(pmlmepriv, pwlan);
+}
+
/*
*rtw_free_assoc_resources: the caller has to lock pmlmepriv->lock
*/
void rtw_free_assoc_resources(struct adapter *adapter, int lock_scanned_queue)
{
- struct wlan_network *pwlan = NULL;
struct mlme_priv *pmlmepriv = &adapter->mlmepriv;
struct sta_priv *pstapriv = &adapter->stapriv;
struct wlan_network *tgt_network = &pmlmepriv->cur_network;
@@ -793,20 +811,13 @@ void rtw_free_assoc_resources(struct adapter *adapter,
int lock_scanned_queue)
rtw_init_bcmc_stainfo(adapter);
}
- if (lock_scanned_queue)
+ if (lock_scanned_queue) {
spin_lock_bh(&(pmlmepriv->scanned_queue.lock));
-
- pwlan = rtw_find_network(&pmlmepriv->scanned_queue,
tgt_network->network.MacAddress);
- if (pwlan)
- pwlan->fixed = false;
- else
- RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_,
("rtw_free_assoc_resources:pwlan==NULL\n\n"));
-
- if ((check_fwstate(pmlmepriv, WIFI_ADHOC_MASTER_STATE) &&
(adapter->stapriv.asoc_sta_count == 1)))
- rtw_free_network_nolock(pmlmepriv, pwlan);
-
- if (lock_scanned_queue)
+ rtw_free_current_network(adapter);
spin_unlock_bh(&pmlmepriv->scanned_queue.lock);
+ } else
+ rtw_free_current_network(adapter);
+
pmlmepriv->key_mask = 0;
}
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86, mce: use mce_usable_address() for UCNA memory error recovery
A machine-check address register (MCi_ADDR) that the processor uses
to report the address or location associated with the logged error.
The address field can hold a virtual (linear) address, a physical
address, or a value indicating an internal physical location, depending
on the type of error. For further information, see the documentation
for particular implementations of the architecture.
-- AMD64 APM Volume 2
The IA32_MCi_ADDR MSR contains the address of the code or data memory
location that produced the machine-check error. The IA32_MCi_ADDR
register is either not implemented or contains no address if the ADDRV
flag in the IA32_MCi_STATUS register is clear. The address returned is
an offset into a segment, linear address, physical address, or memory
address. This depends on the error encountered.
-- Intel SDM Volume 3B
As the comment of `mce_usable_address' suggests, we should check if the
address reported by the CPU is in a format we can parse. This patch aims
to use mce_usable_address() for UCNA/Deferred memory error recovery. For
Intel x86_64 platform mce_usable_address() can work fine, but it doesn't
even matter for AMD platform.
Signed-off-by: Chen Yucong
---
arch/x86/kernel/cpu/mcheck/mce.c | 48 --
1 file changed, 30 insertions(+), 18 deletions(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 800d423..c777626 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -607,6 +607,35 @@ static bool memory_error(struct mce *m)
return false;
}
+/*
+ * Check if the address reported by the CPU is in a format we can parse.
+ * It would be possible to add code for most other cases, but all would
+ * be somewhat complicated (e.g. segment offset would require an instruction
+ * parser). So only support physical addresses up to page granuality for now.
+ */
+static int mce_usable_address(struct mce *m)
+{
+ struct cpuinfo_x86 *c = &boot_cpu_data;
+
+ if (c->x86_vendor == X86_VENDOR_INTEL) {
+ if (!(m->status & MCI_STATUS_MISCV) ||
+ !(m->status & MCI_STATUS_ADDRV))
+ return 0;
+ if (MCI_MISC_ADDR_LSB(m->misc) > PAGE_SHIFT)
+ return 0;
+ if (MCI_MISC_ADDR_MODE(m->misc) != MCI_MISC_ADDR_PHYS)
+ return 0;
+ return 1;
+ } else if (c->x86_vendor == X86_VENDOR_AMD) {
+ /*
+* coming soon
+*/
+ return 0;
+ }
+
+ return 0;
+}
+
DEFINE_PER_CPU(unsigned, mce_poll_count);
/*
@@ -671,7 +700,7 @@ void machine_check_poll(enum mcp_flags flags, mce_banks_t
*b)
* do not add it into the ring buffer.
*/
if (severity == MCE_DEFERRED_SEVERITY && memory_error(&m)) {
- if (m.status & MCI_STATUS_ADDRV) {
+ if (mce_usable_address(&m)) {
mce_ring_add(m.addr >> PAGE_SHIFT);
mce_schedule_work();
}
@@ -976,23 +1005,6 @@ reset:
return ret;
}
-/*
- * Check if the address reported by the CPU is in a format we can parse.
- * It would be possible to add code for most other cases, but all would
- * be somewhat complicated (e.g. segment offset would require an instruction
- * parser). So only support physical addresses up to page granuality for now.
- */
-static int mce_usable_address(struct mce *m)
-{
- if (!(m->status & MCI_STATUS_MISCV) || !(m->status & MCI_STATUS_ADDRV))
- return 0;
- if (MCI_MISC_ADDR_LSB(m->misc) > PAGE_SHIFT)
- return 0;
- if (MCI_MISC_ADDR_MODE(m->misc) != MCI_MISC_ADDR_PHYS)
- return 0;
- return 1;
-}
-
static void mce_clear_state(unsigned long *toclear)
{
int i;
--
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: fanotify bug on gdb -- hard crash
thank you, eric. will do. I read up on it above and now understand it better.
the example in the man page seems somewhat misfortunate. I would use
an example that does not, by default, lock up the user system.
(perhaps add a second example with the _PERM feature that shows how it
responds.)
regards,
/iaw
Ivo Welch (ivo.we...@gmail.com)
http://www.ivo-welch.info/
J. Fred Weston Professor of Finance
Anderson School at UCLA, C519
Director, UCLA Anderson Fink Center for Finance and Investments
Free Finance Textbook, http://book.ivo-welch.info/
Editor, Critical Finance Review, http://www.critical-finance-review.org/
On Mon, Dec 29, 2014 at 12:29 PM, Eric Paris wrote:
> Change FAN_OPEN_PERM to FAN_OPEN
>
> If you have any more deadlocks, please let us know. Once you understand
> the difference between the two let us know if there are any more
> problems...
>
> -Eric
>
> On Mon, 2014-12-29 at 08:13 +0800, ivo welch wrote:
>>
>>
>> I really don't know what I am doing. however, the code is really not
>> mine, but verbatim from the man-page example,
>> http://man7.org/linux/man-pages/man7/fanotify.7.html . I had more
>> code below my code, but had whittled down the example to illustrate
>> where my system locks up.
>>
>>
>> I wonder if there could be safeguards in the call to avoid crashing
>> the system. I know fanotify is playing with fire, but should it
>> incapacitate the system in this way?
>>
>>
>> in the end, all I want to do is log each and every file-open operation
>> asap. I want to do read-only probing. could someone please point me
>> to a correct example or facility if the manpage is wrong.
>>
>>
>> /iaw
>>
>>
>>
>>
>> Ivo Welch (ivo.we...@gmail.com)
>> http://www.ivo-welch.info/
>> J. Fred Weston Professor of Finance
>> Anderson School at UCLA, C519
>> Director, UCLA Anderson Fink Center for Finance and Investments
>> Free Finance Textbook, http://book.ivo-welch.info/
>> Editor, Critical Finance Review,
>> http://www.critical-finance-review.org/
>>
>>
>> On Mon, Dec 29, 2014 at 7:13 AM, Eric Paris wrote:
>> Why are you setting FAN_OPEN_PERM and then not responding to
>> perm
>> requests? Of course the system is going to appear locked,
>> until you
>> start responding to open events, remove that mark, or close
>> the fanotify
>> fd...
>>
>> -Eric
>>
>> On Fri, 2014-12-26 at 19:40 +0100, Heinrich Schuchardt wrote:
>> > Hello Ivo,
>> >
>> > On 26.12.2014 15:45, ivo welch wrote:
>> > > I am not a kernel developer, so forgive the intrusion.
>> > >
>> > > I suspect I have found either a bug in gdb (less likely)
>> or a bug in
>> > > fanotify (more likely). it is replicable, and the code is
>> almost
>> > > unchanged from the example in the fanotify man page. to
>> trigger it,
>> > > all an su needs to do is to step through the program below
>> with gdb
>> > > 7.8.1 'n' command, and linux locks up the system pretty
>> hard (reboot
>> > > required). I have confirmed the replicability of this
>> issue on a
>> > > clean arch 2014.12.01 3.17.6-1 system and on a clean
>> ubuntu 14.10
>> > > system, both VMs created just to check it. /iaw
>> > >
>> > >
>> > > #define _GNU_SOURCE /* Needed to get O_LARGEFILE
>> definition */
>> > > #include
>> > > #include
>> > > #include
>> > > #include
>> > > #include
>> > > #include
>> > >
>> > > int main(int argc, char *argv[]) {
>> > >int fd;
>> > >fd = fanotify_init(FAN_CLOEXEC | FAN_CLASS_CONTENT |
>> FAN_NONBLOCK,
>> > > O_RDONLY | O_LARGEFILE);
>> > >if (fd == -1) exit(1);
>> > >fprintf(stderr, "calling fanotify_mark: fd=%d\n", fd);
>> > >if (fanotify_mark(fd, FAN_MARK_ADD | FAN_MARK_MOUNT,
>> FAN_OPEN_PERM |
>> > > FAN_CLOSE_WRITE, -1, "/") == -1) exit(2);
>> > >fprintf(stderr, "in gdb step through with 'n' for
>> repeat.\n");
>> > >fprintf(stderr, " (and sometimes otherwise), a ^C
>> works, but a ^Z
>> > > and then ^C does not.\n");
>> > > }
>> >
>> > I was not able to reproduce your problem according to your
>> description
>> > with Ubuntu 14.10.
>> >
>> > I ran a Ubuntu 14.04 amd64 LiveImage in a VM and compiled
>> your example with
>> > gcc -g -o test test.c
>> >
>> > The gdb version in Ubuntu 14.10 is 7.4 and not 7.8.1. The
>> kernel version
>> > is 3.13.
>> >
>> > root@ubuntu:/home/ubuntu/temp# gdb ./test
>> > GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
>> > Copyright (C) 2012 Free Software Foundation, Inc.
>>
Re: [PATCH v3 00/20] kselftest install target feature
On Wed, 2014-12-24 at 09:27 -0700, Shuah Khan wrote: > This patch series adds a new kselftest_install make target > to enable selftest install. When make kselftest_install is > run, selftests are installed on the system. A new install > target is added to selftests Makefile which will install > targets for the tests that are specified in INSTALL_TARGETS. > During install, a script is generated to run tests that are > installed. This script will be installed in the selftest install > directory. Individual test Makefiles are changed to add to the > script. This will allow new tests to add install and run test > commands to the generated kselftest script. kselftest target > now depends on kselftest_install and runs the generated kselftest > script to reduce duplicate work and for common look and feel when > running tests. > > This approach leverages and extends the existing framework that > uses makefile targets to implement run_tests and adds install > target. This will scale well as new tests get added and makes > it easier for test writers to add install target at the same > time new test gets added. > > This v3 series reduces duplicate code to generate script > in indiviual test Makefiles and consolidates support in > selftests main Makefile. In the main Makefile, it does > minimal work to set and export install path. In this > series exec and powerpc tests are not included in the > install, this work will be done in future patches. exec > and powerpc are still run when make kselftest is invoked. Any particular reason you excluded the powerpc tests? Going by a quick count, powerpc has 32 of the 54 self tests, ie. more than half. Sorry I didn't get a chance to review v1 or v2, but is this really the best solution we can come up with? It seems to involve a lot of boiler plate getting repeated in every Makefile. I'm off this week so I can't immediately come up with something better, I'll try in the new year. cheers -- 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 15/27] net: sxgbe: Use setup_timer
--- Original Message ---
Sender : Julia Lawall
Date : Dec 26, 2014 20:05 (GMT+05:30)
Title : [PATCH 15/27] net: sxgbe: Use setup_timer
Convert a call to init_timer and accompanying intializations of
the timer's data and function fields to a call to setup_timer.
A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@@
expression t,f,d;
@@
-init_timer(&t);
+setup_timer(&t,f,d);
-t.function = f;
-t.data = d;
//
Signed-off-by: Julia Lawall
---
drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
index 6984944..b6612d6 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
@@ -133,9 +133,8 @@ bool sxgbe_eee_init(struct sxgbe_priv_data * const priv)
return false;
priv->eee_active = 1;
- init_timer(&priv->eee_ctrl_timer);
- priv->eee_ctrl_timer.function = sxgbe_eee_ctrl_timer;
- priv->eee_ctrl_timer.data = (unsigned long)priv;
+ setup_timer(&priv->eee_ctrl_timer, sxgbe_eee_ctrl_timer,
+ (unsigned long)priv);
priv->eee_ctrl_timer.expires = SXGBE_LPI_TIMER(eee_timer);
add_timer(&priv->eee_ctrl_timer);
@@ -1009,10 +1008,9 @@ static void sxgbe_tx_init_coalesce(struct
sxgbe_priv_data *priv)
struct sxgbe_tx_queue *p = priv->txq[queue_num];
p->tx_coal_frames = SXGBE_TX_FRAMES;
p->tx_coal_timer = SXGBE_COAL_TX_TIMER;
- init_timer(&p->txtimer);
+ setup_timer(&p->txtimer, sxgbe_tx_timer,
+ (unsigned long)&priv->txq[queue_num]);
p->txtimer.expires = SXGBE_COAL_TIMER(p->tx_coal_timer);
- p->txtimer.data = (unsigned long)&priv->txq[queue_num];
- p->txtimer.function = sxgbe_tx_timer;
add_timer(&p->txtimer);
}
}
Looks good to me.
Acked by: Girish K S
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±‘êçzX§¶›¡Ü¨}©ž²Æ
zÚ&j:+v‰¨¾«‘êçzZ+€Ê+zf£¢·hšˆ§~††Ûiÿûàz¹ ®w¥¢¸?™¨èÚ&¢)ߢf”ù^jÇ«y§m…á@A«a¶Úÿ
0¶ìh®å’i
Re: fanotify bug on gdb -- hard crash
Change FAN_OPEN_PERM to FAN_OPEN
If you have any more deadlocks, please let us know. Once you understand
the difference between the two let us know if there are any more
problems...
-Eric
On Mon, 2014-12-29 at 08:13 +0800, ivo welch wrote:
>
>
> I really don't know what I am doing. however, the code is really not
> mine, but verbatim from the man-page example,
> http://man7.org/linux/man-pages/man7/fanotify.7.html . I had more
> code below my code, but had whittled down the example to illustrate
> where my system locks up.
>
>
> I wonder if there could be safeguards in the call to avoid crashing
> the system. I know fanotify is playing with fire, but should it
> incapacitate the system in this way?
>
>
> in the end, all I want to do is log each and every file-open operation
> asap. I want to do read-only probing. could someone please point me
> to a correct example or facility if the manpage is wrong.
>
>
> /iaw
>
>
>
>
> Ivo Welch (ivo.we...@gmail.com)
> http://www.ivo-welch.info/
> J. Fred Weston Professor of Finance
> Anderson School at UCLA, C519
> Director, UCLA Anderson Fink Center for Finance and Investments
> Free Finance Textbook, http://book.ivo-welch.info/
> Editor, Critical Finance Review,
> http://www.critical-finance-review.org/
>
>
> On Mon, Dec 29, 2014 at 7:13 AM, Eric Paris wrote:
> Why are you setting FAN_OPEN_PERM and then not responding to
> perm
> requests? Of course the system is going to appear locked,
> until you
> start responding to open events, remove that mark, or close
> the fanotify
> fd...
>
> -Eric
>
> On Fri, 2014-12-26 at 19:40 +0100, Heinrich Schuchardt wrote:
> > Hello Ivo,
> >
> > On 26.12.2014 15:45, ivo welch wrote:
> > > I am not a kernel developer, so forgive the intrusion.
> > >
> > > I suspect I have found either a bug in gdb (less likely)
> or a bug in
> > > fanotify (more likely). it is replicable, and the code is
> almost
> > > unchanged from the example in the fanotify man page. to
> trigger it,
> > > all an su needs to do is to step through the program below
> with gdb
> > > 7.8.1 'n' command, and linux locks up the system pretty
> hard (reboot
> > > required). I have confirmed the replicability of this
> issue on a
> > > clean arch 2014.12.01 3.17.6-1 system and on a clean
> ubuntu 14.10
> > > system, both VMs created just to check it. /iaw
> > >
> > >
> > > #define _GNU_SOURCE /* Needed to get O_LARGEFILE
> definition */
> > > #include
> > > #include
> > > #include
> > > #include
> > > #include
> > > #include
> > >
> > > int main(int argc, char *argv[]) {
> > >int fd;
> > >fd = fanotify_init(FAN_CLOEXEC | FAN_CLASS_CONTENT |
> FAN_NONBLOCK,
> > > O_RDONLY | O_LARGEFILE);
> > >if (fd == -1) exit(1);
> > >fprintf(stderr, "calling fanotify_mark: fd=%d\n", fd);
> > >if (fanotify_mark(fd, FAN_MARK_ADD | FAN_MARK_MOUNT,
> FAN_OPEN_PERM |
> > > FAN_CLOSE_WRITE, -1, "/") == -1) exit(2);
> > >fprintf(stderr, "in gdb step through with 'n' for
> repeat.\n");
> > >fprintf(stderr, " (and sometimes otherwise), a ^C
> works, but a ^Z
> > > and then ^C does not.\n");
> > > }
> >
> > I was not able to reproduce your problem according to your
> description
> > with Ubuntu 14.10.
> >
> > I ran a Ubuntu 14.04 amd64 LiveImage in a VM and compiled
> your example with
> > gcc -g -o test test.c
> >
> > The gdb version in Ubuntu 14.10 is 7.4 and not 7.8.1. The
> kernel version
> > is 3.13.
> >
> > root@ubuntu:/home/ubuntu/temp# gdb ./test
> > GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
> > Copyright (C) 2012 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later
> >
> > This is free software: you are free to change and
> redistribute it.
> > There is NO WARRANTY, to the extent permitted by law. Type
> "show copying"
> > and "show warranty" for details.
> > This GDB was configured as "x86_64-linux-gnu".
> > For bug reporting instructions, please see:
> >
Re: [PATCH 1/2] tty: serial: 8250_mtk: Add earlycon
Hi Rob,
On Fri, 2014-12-26 at 15:24 -0600, Rob Herring wrote:
> On Thu, Dec 18, 2014 at 2:33 AM, Eddie Huang wrote:
> > Mediatek UART has highspeed register, but 8250_early.c doesn't
> > support this, so add earlycon in 8250_mtk.c
>
> I don't see any highspeed register setup here. More generically,
> aren't you just skipping any UART setup? That may be useful on other
> platforms with 8250s, too. With the kernel command line version, you
> could perhaps add a "noinit" flag. The DT case is harder, and I'm not
> sure how we should handle that. We could perhaps add a
> "stdout-path-initialized" flag to chosen.
>
Yes, I skipped UART setup same as msm_serial.c and amba-pl011.c
(although they are standalone serial driver). Just like earlyprintk, I
think earlycon should reuse UART setting in loader. Since some other
platforms with 8250 already depend on this, it's ok to add flags to
distinguish whether 8250 earlycon driver should init hw or not. As you
said, add "noinit" flag is simple, but "stdout-path-initialized" need
more discussion.
> >
> > Signed-off-by: Eddie Huang
> > ---
> > drivers/tty/serial/8250/8250_mtk.c | 33 +
> > 1 file changed, 33 insertions(+)
> >
> > diff --git a/drivers/tty/serial/8250/8250_mtk.c
> > b/drivers/tty/serial/8250/8250_mtk.c
> > index de7aae5..65dd569 100644
> > --- a/drivers/tty/serial/8250/8250_mtk.c
> > +++ b/drivers/tty/serial/8250/8250_mtk.c
> > @@ -23,6 +23,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "8250.h"
> >
> > @@ -289,6 +290,38 @@ static struct platform_driver mtk8250_platform_driver
> > = {
> > };
> > module_platform_driver(mtk8250_platform_driver);
> >
> > +#define BOTH_EMPTY (UART_LSR_TEMT | UART_LSR_THRE)
> > +
> > +static void __init mtk8250_serial_putc(struct uart_port *port, int c)
> > +{
> > + while ((readl(port->membase + (UART_LSR << 2)) & BOTH_EMPTY) !=
> > + BOTH_EMPTY)
> > + ;
> > + writel(c, port->membase + (UART_TX << 2));
> > +}
> > +
> > +static void __init early_mtk8250_write(struct console *console,
> > + const char *s, unsigned int count)
>
> Is there a reason early_serial8250_write can't work for you other than
> it is currently static?
>
> Rob
>
The reason is only static. I want to keep 8250_early.c untouchable, all
modifications in 8250_mtk.c
--
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] cpufreq: suspend cpufreq governors on shutdown
On 24 December 2014 at 11:39, Doug Anderson wrote:
> We should stop cpufreq governors when we shut down the system. If we
> don't do this, we can end up with this deadlock:
>
> 1. cpufreq governor may be running on a CPU other than CPU0.
> 2. In machine_restart() we call smp_send_stop() which stops CPUs.
>If one of these CPUs was actively running a cpufreq governor
>then it may have the mutex / spinlock needed to access the main
>PMIC in the system (perhaps over I2C)
> 3. If a machine needs access to the main PMIC in order to shutdown
>then it will never get it since the mutex was lost when the other
>CPU stopped.
> 4. We'll hang (possibly eventually hitting the hard lockup detector).
>
> Let's avoid the problem by stopping the cpufreq governor at shutdown,
> which is a sensible thing to do anyway.
>
> Signed-off-by: Doug Anderson
> ---
> Changes in v2:
> - Add a comment about why we register
> - Don't create cpufreq_shutdown() wrapper function
>
> drivers/cpufreq/cpufreq.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index a09a29c..33f3d65 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -2550,6 +2551,14 @@ int cpufreq_unregister_driver(struct cpufreq_driver
> *driver)
> }
> EXPORT_SYMBOL_GPL(cpufreq_unregister_driver);
>
> +/*
> + * Stop cpufreq at shutdown to make sure it isn't holding any locks
> + * or mutexes when secondary CPUs are halted.
> + */
> +static struct syscore_ops cpufreq_syscore_ops = {
> + .shutdown = cpufreq_suspend,
> +};
> +
> static int __init cpufreq_core_init(void)
> {
> if (cpufreq_disabled())
> @@ -2558,6 +2567,8 @@ static int __init cpufreq_core_init(void)
> cpufreq_global_kobject = kobject_create();
> BUG_ON(!cpufreq_global_kobject);
>
> + register_syscore_ops(&cpufreq_syscore_ops);
> +
> return 0;
> }
> core_initcall(cpufreq_core_init);
Acked-by: Viresh Kumar
--
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 v18 10/11] ARM: kprobes: check register usage for probed instruction.
This patch utilizes previous introduced checker to check register usage
for probed ARM instruction and saves it in a mask. Futher patch will
use such information to avoid simuation or emulation.
Signed-off-by: Wang Nan
---
arch/arm/include/asm/probes.h | 12
arch/arm/probes/decode.c | 7 ++
arch/arm/probes/kprobes/actions-arm.c | 2 +-
arch/arm/probes/kprobes/checkers-arm.c | 124 +
arch/arm/probes/kprobes/checkers.h | 1 +
5 files changed, 145 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/probes.h b/arch/arm/include/asm/probes.h
index f0a1ee8..ee04067 100644
--- a/arch/arm/include/asm/probes.h
+++ b/arch/arm/include/asm/probes.h
@@ -41,6 +41,18 @@ struct arch_probes_insn {
probes_insn_singlestep_t*insn_singlestep;
probes_insn_fn_t*insn_fn;
int stack_space;
+
+ /* Use 2 bits for a register. One more bit for extension */
+#define REG_NO_USE (0)
+#define REG_USE(1)
+#define REG_MASK (3)
+#define __register_usage_flag(n, f)((f) << ((n) * 2))
+#define __register_usage_mask(n) (REG_MASK << ((n) * 2))
+#define __clean_register_flag(m, n)((m) & (~(__register_usage_mask(n
+#define __set_register_flag(m, n, f) (__clean_register_flag(m, n) |
__register_usage_flag(n, f))
+#define set_register_nouse(m, n) do {(m) = __set_register_flag(m, n,
REG_NO_USE);} while(0)
+#define set_register_use(m, n) do {(m) = __set_register_flag(m, n,
REG_USE);} while(0)
+ int register_usage_mask;
};
#endif /* __ASSEMBLY__ */
diff --git a/arch/arm/probes/decode.c b/arch/arm/probes/decode.c
index f9d7c42..d60a1b2 100644
--- a/arch/arm/probes/decode.c
+++ b/arch/arm/probes/decode.c
@@ -435,6 +435,13 @@ probes_decode_insn(probes_opcode_t insn, struct
arch_probes_insn *asi,
*/
asi->stack_space = 0;
+ /*
+* Similay to stack_space, register_usage_mask is filled by
+* checkers. Its default value is set to ~0, which is 'all
+* registers are used', to prevent any potential optimization.
+*/
+ asi->register_usage_mask = ~(0UL);
+
if (emulate)
insn = prepare_emulated_insn(insn, asi, thumb);
diff --git a/arch/arm/probes/kprobes/actions-arm.c
b/arch/arm/probes/kprobes/actions-arm.c
index 4fedd4c..26e435b 100644
--- a/arch/arm/probes/kprobes/actions-arm.c
+++ b/arch/arm/probes/kprobes/actions-arm.c
@@ -340,4 +340,4 @@ const union decode_action
kprobes_arm_actions[NUM_PROBES_ARM_ACTIONS] = {
[PROBES_LDMSTM] = {.decoder = kprobe_decode_ldmstm}
};
-const struct decode_checker *kprobes_arm_checkers[] = {arm_stack_checker,
NULL};
+const struct decode_checker *kprobes_arm_checkers[] = {arm_stack_checker,
arm_regs_checker, NULL};
diff --git a/arch/arm/probes/kprobes/checkers-arm.c
b/arch/arm/probes/kprobes/checkers-arm.c
index f817663..df1d77b 100644
--- a/arch/arm/probes/kprobes/checkers-arm.c
+++ b/arch/arm/probes/kprobes/checkers-arm.c
@@ -97,3 +97,127 @@ const struct decode_checker
arm_stack_checker[NUM_PROBES_ARM_ACTIONS] = {
[PROBES_STORE] = {.checker = arm_check_stack},
[PROBES_LDMSTM] = {.checker = arm_check_stack},
};
+
+static enum probes_insn __kprobes arm_check_regs_nouse(probes_opcode_t insn,
+ struct arch_probes_insn *asi,
+ const struct decode_header *h)
+{
+ asi->register_usage_mask = 0;
+ return INSN_GOOD;
+}
+
+static void __arm_check_regs(probes_opcode_t insn,
+ const struct decode_header *h,
+ int *quintuple)
+{
+ int i;
+ u32 regs = h->type_regs.bits >> DECODE_TYPE_BITS;
+ probes_opcode_t mask, shifted;
+
+ memset(quintuple, 0xff, sizeof(int) * 5);
+ for (i = 0, shifted = insn, mask = 0xf; regs != 0;
+ regs >>= 4, mask <<= 4, shifted >>= 4, i++)
+ if (regs & 0xf)
+ quintuple[i] = shifted & 0xf;
+}
+
+static enum probes_insn arm_check_regs_normal(probes_opcode_t insn,
+ struct arch_probes_insn *asi,
+ const struct decode_header *h)
+{
+ int quintuple[5], i;
+ asi->register_usage_mask = 0;
+ __arm_check_regs(insn, h, quintuple);
+ for (i = 0; i < 5; i++) {
+ int r = quintuple[i];
+ if (r < 0)
+ continue;
+ set_register_use(asi->register_usage_mask, r);
+ }
+
+ return INSN_GOOD;
+}
+
+static enum probes_insn arm_check_regs_ldmstm(probes_opcode_t insn,
+ struct arch_probes_insn *asi,
+ const struct decode_header *h)
+{
+ unsigned int reglist = insn & 0x;
+ unsigned int rn = (insn >> 16) & 0xf;
+ int i;
+
+ set_register_use(asi->register_usage_mask, rn);
+ for (i = 0; reglist > 0; i++, reglist >>= 1)
+ if (reglist & 1)
+ set_registe
Re: [PATCH v17 11/11] ARM: optprobes: execute instruction during restoring if possible.
On 2014/12/29 6:10, Masami Hiramatsu wrote:
> (2014/12/27 16:36), Wang Nan wrote:
>> This patch removes software emulation or simulation for most of probed
>> instructions. If the instruction doesn't use PC relative addressing,
>> it will be translated into following instructions in the restore code
>> in code template:
>>
>> ldmia {r0 - r14} // restore all instruction except PC
>> // direct execute the probed instruction
>> b next_insn // branch to next instruction.
>>
>> Signed-off-by: Wang Nan
>> ---
>> arch/arm/include/asm/kprobes.h| 3 +++
>> arch/arm/include/asm/probes.h | 1 +
>> arch/arm/probes/kprobes/opt-arm.c | 47
>> +--
>> 3 files changed, 49 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/kprobes.h b/arch/arm/include/asm/kprobes.h
>> index 50ff3bc..3ea9be5 100644
>> --- a/arch/arm/include/asm/kprobes.h
>> +++ b/arch/arm/include/asm/kprobes.h
>> @@ -57,6 +57,9 @@ extern __visible kprobe_opcode_t optprobe_template_call;
>> extern __visible kprobe_opcode_t optprobe_template_end;
>> extern __visible kprobe_opcode_t optprobe_template_sub_sp;
>> extern __visible kprobe_opcode_t optprobe_template_add_sp;
>> +extern __visible kprobe_opcode_t optprobe_template_restore_begin;
>> +extern __visible kprobe_opcode_t optprobe_template_restore_orig_insn;
>> +extern __visible kprobe_opcode_t optprobe_template_restore_end;
>>
>> #define MAX_OPTIMIZED_LENGTH4
>> #define MAX_OPTINSN_SIZE\
>> diff --git a/arch/arm/include/asm/probes.h b/arch/arm/include/asm/probes.h
>> index ee8725c..8ebbe83 100644
>> --- a/arch/arm/include/asm/probes.h
>> +++ b/arch/arm/include/asm/probes.h
>> @@ -50,6 +50,7 @@ struct arch_probes_insn {
>> #define set_register_nouse(m, n)__clear_register_flag(m, n, REG_NO_USE)
>> #define set_register_use(m, n) __set_register_flag(m, n, REG_USE)
>> int register_usage_mask;
>> +bool kprobe_direct_exec;
>> };
>>
>> #endif /* __ASSEMBLY__ */
>> diff --git a/arch/arm/probes/kprobes/opt-arm.c
>> b/arch/arm/probes/kprobes/opt-arm.c
>> index 6a60df3..f3bd1cc 100644
>> --- a/arch/arm/probes/kprobes/opt-arm.c
>> +++ b/arch/arm/probes/kprobes/opt-arm.c
>> @@ -32,6 +32,13 @@
>> #include "core.h"
>>
>> /*
>> + * See register_usage_mask. If the probed instruction doesn't use PC,
>> + * we can copy it into template and have it executed directly without
>> + * simulation or emulation.
>> + */
>> +#define can_kprobe_direct_exec(m) (!((m) & 0xc000UL))
>
> I think you'd better define a macro for this bitmask.
>
>
>> +
>> +/*
>> * NOTE: the first sub and add instruction will be modified according
>> * to the stack cost of the instruction.
>> */
>> @@ -66,7 +73,15 @@ asm (
>> " orrne r2, #1\n"
>> " strne r2, [sp, #60] @ set bit0 of PC for
>> thumb\n"
>> " msr cpsr_cxsf, r1\n"
>> +".global optprobe_template_restore_begin\n"
>> +"optprobe_template_restore_begin:\n"
>> " ldmia sp, {r0 - r15}\n"
>> +".global optprobe_template_restore_orig_insn\n"
>> +"optprobe_template_restore_orig_insn:\n"
>> +" nop\n"
>> +".global optprobe_template_restore_end\n"
>> +"optprobe_template_restore_end:\n"
>> +" ldmia sp, {r13 - r15}\n"
>
> Why this can't be a nop too?
>
> Thank you,
>
Good suggestion. I'll send a new version of patch 10 and 11.
Thank you.
--
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 v18 11/11] ARM: optprobes: execute instruction during restoring if possible.
This patch removes software emulation or simulation for most of probed
instructions. If the instruction doesn't use PC relative addressing,
it will be translated into following instructions in the restore code
in code template:
ldmia {r0 - r14} // restore all instruction except PC
// direct execute the probed instruction
b next_insn // branch to next instruction.
Signed-off-by: Wang Nan
---
arch/arm/include/asm/kprobes.h| 3 +++
arch/arm/include/asm/probes.h | 1 +
arch/arm/probes/kprobes/opt-arm.c | 51 +--
3 files changed, 53 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/kprobes.h b/arch/arm/include/asm/kprobes.h
index 50ff3bc..3ea9be5 100644
--- a/arch/arm/include/asm/kprobes.h
+++ b/arch/arm/include/asm/kprobes.h
@@ -57,6 +57,9 @@ extern __visible kprobe_opcode_t optprobe_template_call;
extern __visible kprobe_opcode_t optprobe_template_end;
extern __visible kprobe_opcode_t optprobe_template_sub_sp;
extern __visible kprobe_opcode_t optprobe_template_add_sp;
+extern __visible kprobe_opcode_t optprobe_template_restore_begin;
+extern __visible kprobe_opcode_t optprobe_template_restore_orig_insn;
+extern __visible kprobe_opcode_t optprobe_template_restore_end;
#define MAX_OPTIMIZED_LENGTH 4
#define MAX_OPTINSN_SIZE \
diff --git a/arch/arm/include/asm/probes.h b/arch/arm/include/asm/probes.h
index ee04067..9a5c706 100644
--- a/arch/arm/include/asm/probes.h
+++ b/arch/arm/include/asm/probes.h
@@ -53,6 +53,7 @@ struct arch_probes_insn {
#define set_register_nouse(m, n) do {(m) = __set_register_flag(m, n,
REG_NO_USE);} while(0)
#define set_register_use(m, n) do {(m) = __set_register_flag(m, n,
REG_USE);} while(0)
int register_usage_mask;
+ bool kprobe_direct_exec;
};
#endif /* __ASSEMBLY__ */
diff --git a/arch/arm/probes/kprobes/opt-arm.c
b/arch/arm/probes/kprobes/opt-arm.c
index 6a60df3..3af42cc 100644
--- a/arch/arm/probes/kprobes/opt-arm.c
+++ b/arch/arm/probes/kprobes/opt-arm.c
@@ -32,6 +32,13 @@
#include "core.h"
/*
+ * See register_usage_mask. If the probed instruction doesn't use PC,
+ * we can copy it into template and have it executed directly without
+ * simulation or emulation.
+ */
+#define can_kprobe_direct_exec(m) (!((m) & __register_usage_mask(15)))
+
+/*
* NOTE: the first sub and add instruction will be modified according
* to the stack cost of the instruction.
*/
@@ -66,7 +73,15 @@ asm (
" orrne r2, #1\n"
" strne r2, [sp, #60] @ set bit0 of PC for
thumb\n"
" msr cpsr_cxsf, r1\n"
+ ".global optprobe_template_restore_begin\n"
+ "optprobe_template_restore_begin:\n"
" ldmia sp, {r0 - r15}\n"
+ ".global optprobe_template_restore_orig_insn\n"
+ "optprobe_template_restore_orig_insn:\n"
+ " nop\n"
+ ".global optprobe_template_restore_end\n"
+ "optprobe_template_restore_end:\n"
+ " nop\n"
".global optprobe_template_val\n"
"optprobe_template_val:\n"
"1: .long 0\n"
@@ -86,6 +101,12 @@ asm (
((unsigned long *)&optprobe_template_add_sp - (unsigned long
*)&optprobe_template_entry)
#define TMPL_SUB_SP \
((unsigned long *)&optprobe_template_sub_sp - (unsigned long
*)&optprobe_template_entry)
+#define TMPL_RESTORE_BEGIN \
+ ((unsigned long *)&optprobe_template_restore_begin - (unsigned long
*)&optprobe_template_entry)
+#define TMPL_RESTORE_ORIGN_INSN \
+ ((unsigned long *)&optprobe_template_restore_orig_insn - (unsigned long
*)&optprobe_template_entry)
+#define TMPL_RESTORE_END \
+ ((unsigned long *)&optprobe_template_restore_end - (unsigned long
*)&optprobe_template_entry)
/*
* ARM can always optimize an instruction when using ARM ISA, except
@@ -155,8 +176,12 @@ optimized_callback(struct optimized_kprobe *op, struct
pt_regs *regs)
__this_cpu_write(current_kprobe, NULL);
}
- /* In each case, we must singlestep the replaced instruction. */
- op->kp.ainsn.insn_singlestep(p->opcode, &p->ainsn, regs);
+ /*
+* We singlestep the replaced instruction only when it can't be
+* executed directly during restore.
+*/
+ if (!p->ainsn.kprobe_direct_exec)
+ op->kp.ainsn.insn_singlestep(p->opcode, &p->ainsn, regs);
local_irq_restore(flags);
}
@@ -238,6 +263,28 @@ int arch_prepare_optimized_kprobe(struct optimized_kprobe
*op, struct kprobe *or
val = (unsigned long)optimized_callback;
code[TMPL_CALL_IDX] = val;
+ /* If possible, copy insn and have it executed during restore */
+ orig->ainsn.kpro
Re: [PATCH] fs: overlayfs: Fix coding style issues, missing a blank line after declarations
On Sun, 28 Dec 2014, Joe Perches wrote: > On Mon, 2014-12-29 at 02:49 +, Al Viro wrote: > > On Mon, Dec 29, 2014 at 02:39:39AM +, Al Viro wrote: > > > On Sun, Dec 28, 2014 at 11:56:53AM +0600, Alexander Kuleshov wrote: > > > > Signed-off-by: Alexander Kuleshov > > > > --- > > > > > > For the record: anything of that sort against fs/*.c will be flushed down > > > the toilet where such valuable contributions belong. Don't even bother. > > > > Joe, could you please explain what has driven you to include that into > > scripts/checkpatch.pl and open the countless sphincters? Aren't we > > getting enough pointless patches as it is? > > I don't care for that style actually. > It was Andrew Morton that wanted it used globally. > > I wanted it to be a --strict test and only for > net/ and drivers/net/ where David Miller prefers > that style. > > https://lkml.org/lkml/2014/3/6/550 Although I am guilty of inflicting it on others, just so their patches keep checkpatch.pl quiet, I have been finding this rule very counter- productive, and often at odds with long-established good practice. It makes sense at the head of a substantial function declaring a collection of variables; but Alexander's patch gives many fine examples of where it is stupid, and thank you to him for showing it up so well. In a wrapper function which finds it convenient to declare and assign a variable before doing a line or two and returning, a common pattern, a blank line is just distracting hot air to pacify checkpatch.pl. In a block which needs one extra local variable to do its work, I find the rule pushes me to move that declaration to the head of the function instead of keeping it local to the block, just to avoid the unnecessary blank line. Please rescind or refine the rule - thanks. Hugh -- 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] clk: mxs: Fix invalid 32-bit access to frac registers
On Sunday, December 28, 2014 at 11:26:42 AM, Stefan Wahren wrote: > According to i.MX23 and i.MX28 reference manual the fractional > clock control registers must be addressed by byte instructions. > > This patch fixes the erroneous 32-bit access to these registers > and extends the comment in the init functions. > > Btw the imx23 init now uses a R-M-W sequence just like imx28 init > to avoid any clock glitches. > > The changes has been tested only with a i.MX28 board, because i don't > have access to an i.MX23 board. > > Signed-off-by: Stefan Wahren I don't see a problem, Reviewed-by: Marek Vasut Best regards, Marek Vasut -- 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] UBI: Extend UBI layer debug/messaging capabilities
On 2014/11/3 21:58, Tanya Brokhman wrote: > If there is more then one UBI device mounted, there is no way to > distinguish between messages from different UBI devices. > Add device number to all ubi layer message types. > > The R/O block driver messages were replaced by pr_* since > ubi_device structure is not used by it. > > Amended a bit by Artem. > > Signed-off-by: Tanya Brokhman > Signed-off-by: Artem Bityutskiy > --- > Changes from V1: Hi Artem and Tanya, Do you think the similar effort is worth to be done on ubifs-level? We could have several ubifs partition mounted on a host. Thanks, Hu -- 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/10] iommu/vt-d: Fix intel vt-d faults in kdump kernel
Hi Takao Indoh,
Happy New Year, and thank you very much for you help. The flush is quite
a problem, as there are several places the flush function should be called,
I think the flush should be placed in functions like __iommu_update_old_*.
Created a small patch for this, it is attached.
As I cannot reproduce your problems on my system, so could you please try
these steps?
1. Apply the latest patchset, including 9/10 and 10/10, and then apply the
attached patch_for_flush.patch. And then test the kernel.
2. If 1 does not fix the DMAR fault problems, then it might be caused by
7/10, so please *unpatch* it from the kernel (others and the attached one
should be patched), and then test the kernel.
Regards
Zhenhua
On 12/26/2014 03:27 PM, Takao Indoh wrote:
> On 2014/12/26 15:46, Li, ZhenHua wrote:
>> Hi Takao Indoh,
>>
>> Thank you very much for your testing. I will add your update in next
>> version.
>> Also I think a flush for __iommu_update_old_root_entry is also necessary.
>>
>> Currently I have no idea about your fault, does it happen before or
>> during its loading? Could you send me your full kernel log as an
>> attachment?
> Sure, see attached file.
>
> I removed 9/10 and 10/10 patches from my kernel to avoid panic problem I
> reported in previous mail, and then tested kdump. So please ignore
> intr-remap fault message in log file. Also please ignore stack trace
> starting with the following message, it's a problem of my box.
>
> Flags mismatch irq 0. 0080 (i801_smbus) vs. 00015a00 (timer)
>
> Thanks,
> Takao Indoh
>
>> Regards and Merry Christmas.
>> Zhenhua
>>
>> On 12/26/2014 01:13 PM, Takao Indoh wrote:
>>> Hi Zhen-Hua,
>>>
>>> I tested your patch and found two problems.
>>>
>>> [1]
>>> Kenel panic occurs during 2nd kernel boot.
>>>
>>> ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
>>> Kernel panic - not syncing: timer doesn't work through Interrupt-remapped
>>> IO-APIC
>>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.0 #25
>>> Hardware name: FUJITSU-SV PRIMERGY BX920 S2/D3030, BIOS 080015
>>> Rev.3D81.3030 02/10/2012
>>> 0002 880036167d08 815b1c6a
>>> 817f7670 880036167d88 815b19f1 0008
>>> 880036167d98 880036167d38 810a5d2f 880036167d98
>>> Call Trace:
>>> [] dump_stack+0x48/0x5e
>>> [] panic+0xbb/0x1fa
>>> [] ? vprintk_default+0x1f/0x30
>>> [] panic_if_irq_remap+0x1c/0x20
>>> [] check_timer+0x1e7/0x5ed
>>> [] ? radix_tree_lookup+0xd/0x10
>>> [] setup_IO_APIC+0x261/0x292
>>> [] native_smp_prepare_cpus+0x214/0x25d
>>> [] kernel_init_freeable+0x1dc/0x28c
>>> [] ? rest_init+0x80/0x80
>>> [] kernel_init+0xe/0xf0
>>> [] ret_from_fork+0x7c/0xb0
>>> [] ? rest_init+0x80/0x80
>>> ---[ end Kernel panic - not syncing: timer doesn't work through
>>> Interrupt-remapped IO-APIC
>>>
>>>
>>> This panic seems to be related to unflushed cache. I confirmed this
>>> problem was fixed by the following patch.
>>>
>>> --- a/drivers/iommu/intel_irq_remapping.c
>>> +++ b/drivers/iommu/intel_irq_remapping.c
>>> @@ -200,8 +200,13 @@ static int modify_irte(int irq, struct irte
>>> *irte_modified)
>>> set_64bit(&irte->high, irte_modified->high);
>>>
>>> #ifdef CONFIG_CRASH_DUMP
>>> - if (is_kdump_kernel())
>>> + if (is_kdump_kernel()) {
>>> __iommu_update_old_irte(iommu, index);
>>> + __iommu_flush_cache(iommu,
>>> + iommu->ir_table->base_old_virt +
>>> + index * sizeof(struct irte),
>>> + sizeof(struct irte));
>>> + }
>>> #endif
>>> __iommu_flush_cache(iommu, irte, sizeof(*irte));
>>>
>>>
>>> [2]
>>> Some DMAR error messages are still found in 2nd kernel boot.
>>>
>>> dmar: DRHD: handling fault status reg 2
>>> dmar: DMAR:[DMA Write] Request device [01:00.0] fault addr ffded000
>>> DMAR:[fault reason 01] Present bit in root entry is clear
>>>
>>> I confiremd your commit 1a2262 was already applied. Any idea?
>>>
>>> Thanks,
>>> Takao Indoh
>>>
>>>
>>> On 2014/12/22 18:15, Li, Zhen-Hua wrote:
This patchset is an update of Bill Sumner's patchset, implements a fix for:
If a kernel boots with intel_iommu=on on a system that supports intel vt-d,
when a panic happens, the kdump kernel will boot with these faults:
dmar: DRHD: handling fault status reg 102
dmar: DMAR:[DMA Read] Request device [01:00.0] fault addr fff8
DMAR:[fault reason 01] Present bit in root entry is clear
dmar: DRHD: handling fault status reg 2
dmar: INTR-REMAP: Request device [[61:00.0] fault index 42
INTR-REMAP:[fault reason 34] Present field in the IRTE entry is clear
On some system, the interrupt remapping fault will also happen even if the
intel_iommu is not set to on, because the interrupt remapping will be
enabled
when x2apic is needed by the system.
The cause of the DMA
Re: [PATCH] fs: overlayfs: Fix coding style issues, missing a blank line after declarations
On Mon, 2014-12-29 at 02:49 +, Al Viro wrote: > On Mon, Dec 29, 2014 at 02:39:39AM +, Al Viro wrote: > > On Sun, Dec 28, 2014 at 11:56:53AM +0600, Alexander Kuleshov wrote: > > > Signed-off-by: Alexander Kuleshov > > > --- > > > > For the record: anything of that sort against fs/*.c will be flushed down > > the toilet where such valuable contributions belong. Don't even bother. > > Joe, could you please explain what has driven you to include that into > scripts/checkpatch.pl and open the countless sphincters? Aren't we > getting enough pointless patches as it is? I don't care for that style actually. It was Andrew Morton that wanted it used globally. I wanted it to be a --strict test and only for net/ and drivers/net/ where David Miller prefers that style. https://lkml.org/lkml/2014/3/6/550 > Al, stongly tempted to try and sneak a patch to checkpatch.pl declaring the > lack of /* See Figure 1 */ within the first 10 lines of a function an offense > against the Gods Of Style. Then sit back and watch the resulting spew... Cool. Awaiting your patch... -- 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] zram: clean up zram_meta_alloc()
On Sun, Dec 21, 2014 at 11:35:41PM +0900, Sergey Senozhatsky wrote: > a trivial clean up of zram_meta_alloc() error handling. > > Signed-off-by: Sergey Senozhatsky Acked-by: Minchan Kim -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: overlayfs: Fix coding style issues, missing a blank line after declarations
On Mon, Dec 29, 2014 at 02:39:39AM +, Al Viro wrote: > On Sun, Dec 28, 2014 at 11:56:53AM +0600, Alexander Kuleshov wrote: > > Signed-off-by: Alexander Kuleshov > > --- > > For the record: anything of that sort against fs/*.c will be flushed down > the toilet where such valuable contributions belong. Don't even bother. Joe, could you please explain what has driven you to include that into scripts/checkpatch.pl and open the countless sphincters? Aren't we getting enough pointless patches as it is? Al, stongly tempted to try and sneak a patch to checkpatch.pl declaring the lack of /* See Figure 1 */ within the first 10 lines of a function an offense against the Gods Of Style. Then sit back and watch the resulting spew... -- 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/11] ARM: tegra: add function to control the GPU rail clamp
On 12/26/2014 04:34 AM, Lucas Stach wrote:
Am Donnerstag, den 25.12.2014, 10:28 +0800 schrieb Vince Hsu:
On 12/24/2014 09:16 PM, Lucas Stach wrote:
Am Dienstag, den 23.12.2014, 18:39 +0800 schrieb Vince Hsu:
The Tegra124 and later Tegra SoCs have a sepatate rail gating register
to enable/disable the clamp. The original function
tegra_powergate_remove_clamping() is not sufficient for the enable
function. So add a new function which is dedicated to the GPU rail
gating. Also don't refer to the powergate ID since the GPU ID makes no
sense here.
Signed-off-by: Vince Hsu
To be honest I don't see the point of this patch.
You are bloating the PMC interface by introducing another exported
function that does nothing different than what the current function
already does.
If you need a way to assert the clamp I would have expected you to
introduce a common function to do this for all power partitions.
I thought about adding an tegra_powergate_assert_clamping(), but that
doesn't make sense to all the power partitions except GPU. Note the
difference in TRM. Any suggestion for the common function?
Is there anything speaking against adding this function and only accept
the GPU partition as valid parameter for now. So at least the interface
stays symmetric and can be easily extended if any future partitions have
similar characteristics as the GPU one.
The register APBDEV_PMC_GPU_RG_CNTRL_0 is only for GPU and can be used
for assertion and deassertion. The APBDEV_PMC_REMOVE_CLAMPING_CMD_0 is
only used for deassertion. If we have any future partitions that can be
asserted by SW like GPU, we can improve the interface then.
Other comments inline.
Regards,
Lucas
---
drivers/soc/tegra/pmc.c | 34 +++---
include/soc/tegra/pmc.h | 2 ++
2 files changed, 25 insertions(+), 11 deletions(-)
diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index a2c0ceb95f8f..7798c530ead1 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -225,17 +225,6 @@ int tegra_powergate_remove_clamping(int id)
return -EINVAL;
/*
-* The Tegra124 GPU has a separate register (with different semantics)
-* to remove clamps.
-*/
- if (tegra_get_chip_id() == TEGRA124) {
- if (id == TEGRA_POWERGATE_3D) {
- tegra_pmc_writel(0, GPU_RG_CNTRL);
- return 0;
- }
- }
-
- /*
* Tegra 2 has a bug where PCIE and VDE clamping masks are
* swapped relatively to the partition ids
*/
@@ -253,6 +242,29 @@ int tegra_powergate_remove_clamping(int id)
EXPORT_SYMBOL(tegra_powergate_remove_clamping);
/**
+ * tegra_powergate_gpu_set_clamping - control GPU-SOC clamps
+ *
+ * The post-Tegra114 chips have a separate rail gating register to configure
+ * clamps.
+ *
+ * @assert: true to assert clamp, and false to remove
+ */
+int tegra_powergate_gpu_set_clamping(bool assert)
Those functions with a bool parameter to set/unset something are really
annoying. Please avoid this pattern. The naming of the original function
is much more intuitive.
But the original function is not sufficient. Maybe add a
tegra_powergate_assert_gpu_clamping()? That way I will prefer to adding
one more removal function for GPU. And then again that's a bloat, too.
+{
+ if (!pmc->soc)
+ return -EINVAL;
+
+ if (tegra_get_chip_id() == TEGRA124) {
+ tegra_pmc_writel(assert ? 1 : 0, GPU_RG_CNTRL);
+ tegra_pmc_readl(GPU_RG_CNTRL);
You are reading the register back here, which to me seems like you are
trying to make sure that the write is flushed. Why is this needed?
I also observed the need to do this while working on Tegra124 PCIe in
Barebox, otherwise the partition wouldn't power up. I didn't have time
to follow up on this yet, so it would be nice if you could explain why
this is needed, or if you don't know ask HW about it.
That's a read fence to assure the post of the previous writes through
Tegra interconnect. (copy-paster from
https://android.googlesource.com/kernel/tegra.git/+/28b107dcb3aa122de8e94e48af548140d519298f)
I see what it does, the question is more about why this is needed.
What is the Tegra interconnect? According to the TRM the Tegra contains
some standard AXI <-> AHB <-> APB bridges. That a read is needed to
assure the write is posted to the APB bus seems to imply that there is
some write buffering in one of those bridges. Can we get this documented
somewhere?
The TRM does mention a read after the write. Check the section 32.2.2.3.
Thanks,
Vince
And isn't it needed for the other partition ungating function too then?
I believe yes.
Regards,
Lucas
--
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.tu
Re: [PATCH] staging: lustre: libcfs: fix sparse warnings about static declaration
Ping.
Thanks for any comments
On Tue, 16 Dec 2014 22:39:38 +0800 from hejia...@gmail.com wrote:
> make sparse happy since these two fuchtion are only used in module.c.
> tested by successful compilation.
>
> Signed-off-by: Jia He
> Cc: Oleg Drokin
> Cc: Andreas Dilger
> Cc: Greg Kroah-Hartman
> ---
> drivers/staging/lustre/lustre/libcfs/module.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/lustre/lustre/libcfs/module.c
> b/drivers/staging/lustre/lustre/libcfs/module.c
> index 2c4fc74..b9ee37c 100644
> --- a/drivers/staging/lustre/lustre/libcfs/module.c
> +++ b/drivers/staging/lustre/lustre/libcfs/module.c
> @@ -42,8 +42,7 @@
> #include "../../include/linux/lnet/lnet.h"
> #include "tracefile.h"
>
> -void
> -kportal_memhog_free (struct libcfs_device_userstate *ldu)
> +static void kportal_memhog_free (struct libcfs_device_userstate *ldu)
> {
> struct page **level0p = &ldu->ldu_memhog_root_page;
> struct page **level1p;
> @@ -86,8 +85,7 @@ kportal_memhog_free (struct libcfs_device_userstate *ldu)
> LASSERT (ldu->ldu_memhog_pages == 0);
> }
>
> -int
> -kportal_memhog_alloc(struct libcfs_device_userstate *ldu, int npages,
> +static int kportal_memhog_alloc(struct libcfs_device_userstate *ldu, int
> npages,
>gfp_t flags)
> {
> struct page **level0p;
--
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] fs: overlayfs: Fix coding style issues, missing a blank line after declarations
On Sun, Dec 28, 2014 at 11:56:53AM +0600, Alexander Kuleshov wrote: > Signed-off-by: Alexander Kuleshov > --- For the record: anything of that sort against fs/*.c will be flushed down the toilet where such valuable contributions belong. Don't even bother. -- 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/3] mm: cma: /proc/cmainfo
Hello, On Fri, Dec 26, 2014 at 05:39:01PM +0300, Stefan I. Strogin wrote: > Hello all, > > Here is a patch set that adds /proc/cmainfo. > > When compiled with CONFIG_CMA_DEBUG /proc/cmainfo will contain information > about about total, used, maximum free contiguous chunk and all currently > allocated contiguous buffers in CMA regions. The information about allocated > CMA buffers includes pid, comm, allocation latency and stacktrace at the > moment of allocation. It just says what you are doing but you didn't say why we need it. I can guess but clear description(ie, the problem what you want to solve with this patchset) would help others to review, for instance, why we need latency, why we need callstack, why we need new wheel rather than ftrace and so on. Thanks. > > Example: > > # cat /proc/cmainfo > CMARegion stat:65536 kB total, 248 kB used,65216 kB max > contiguous chunk > > 0x3240 - 0x32401000 (4 kB), allocated by pid 63 (systemd-udevd), latency > 74 us > [] dma_generic_alloc_coherent+0x86/0x160 > [] rpm_idle+0x1f/0x1f0 > [] dma_generic_alloc_coherent+0x0/0x160 > [] ohci_init+0x1fe/0x430 [ohci_hcd] > [] dma_generic_alloc_coherent+0x0/0x160 > [] ohci_pci_reset+0x4f/0x60 [ohci_pci] > [] usb_add_hcd+0x1fc/0x900 [usbcore] > [] pcibios_set_master+0x38/0x90 > [] usb_hcd_pci_probe+0x176/0x4f0 [usbcore] > [] pci_device_probe+0x6f/0xd0 > [] sysfs_create_link+0x25/0x50 > [] driver_probe_device+0x92/0x3b0 > [] __mutex_lock_slowpath+0x5b/0x90 > [] __driver_attach+0x0/0x80 > [] __driver_attach+0x79/0x80 > [] __driver_attach+0x0/0x80 > > 0x32401000 - 0x32402000 (4 kB), allocated by pid 58 (systemd-udevd), latency > 17 us > [] dmam_coherent_release+0x0/0x90 > [] __kmalloc_track_caller+0x31c/0x380 > [] dma_generic_alloc_coherent+0x86/0x160 > [] dma_generic_alloc_coherent+0x0/0x160 > [] dmam_alloc_coherent+0xb6/0x100 > [] ata_bmdma_port_start+0x43/0x60 [libata] > [] ata_host_start.part.29+0xb8/0x190 [libata] > [] pci_read+0x30/0x40 > [] ata_pci_sff_activate_host+0x29/0x220 [libata] > [] ata_bmdma_interrupt+0x0/0x1f0 [libata] > [] pcibios_set_master+0x38/0x90 > [] piix_init_one+0x44e/0x630 [ata_piix] > [] mutex_lock+0x10/0x20 > [] kernfs_activate+0x63/0xd0 > [] kernfs_add_one+0xc3/0x130 > [] pci_device_probe+0x6f/0xd0 > <...> > > Dmitry Safonov (1): > cma: add functions to get region pages counters > > Stefan I. Strogin (2): > stacktrace: add seq_print_stack_trace() > mm: cma: introduce /proc/cmainfo > > include/linux/cma.h| 2 + > include/linux/stacktrace.h | 4 + > kernel/stacktrace.c| 17 > mm/cma.c | 236 > + > 4 files changed, 259 insertions(+) > > -- > 2.1.0 > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org";> em...@kvack.org -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] bfin_can: move the header file to arch independent location
Hi Oliver,
>-Original Message-
>From: Oliver Hartkopp [mailto:socket...@hartkopp.net]
>Sent: Saturday, December 27, 2014 7:10 PM
>To: Wu, Aaron; adi-buildroot-de...@lists.sourceforge.net;
>w...@grandegger.com; m...@pengutronix.de; linux-...@vger.kernel.org;
>linux-kernel@vger.kernel.org
>Subject: Re: [PATCH] bfin_can: move the header file to arch independent
>location
>
>NACK!
>
>As bfin_can.c is the only user of defines from this include file just add the
>needed(!) defines directly to bfin_can.c
>
>Currently bfin_can.h holds a *lot* of defines that are NOT referenced
>anywhere, e.g. search for MC0 - MC31, MD0 - MD31, RMP0 - RMP31, RML0 -
>RML31
>and lots more in bfin_can.c ...
>
>So the correct way is to check which defines are *really* referenced and add
>these directly to bfin_can.c (the only user) when removing bfin_can.h
Thanks for reply, will merge your idea and be back. Also your comments about
another of my recent patch " Rewrite the blackfin CAN driver into arch
independent style" is welcome.
Best regards,
Aaron
>
>Best regards,
>Oliver
>
>
>On 12/26/2014 04:07 AM, Aaron Wu wrote:
>> bfin_can: move the header file to arch independent location
>>
>> Signed-off-by: Aaron Wu
>> ---
>> arch/blackfin/include/asm/bfin_can.h | 728
>> --
>> drivers/net/can/bfin_can.c |2 +-
>> drivers/net/can/bfin_can.h | 728
>++
>> 3 files changed, 729 insertions(+), 729 deletions(-)
>> delete mode 100644 arch/blackfin/include/asm/bfin_can.h
>> create mode 100644 drivers/net/can/bfin_can.h
>>
>> diff --git a/arch/blackfin/include/asm/bfin_can.h
>b/arch/blackfin/include/asm/bfin_can.h
>> deleted file mode 100644
>> index b1492e0..000
>> --- a/arch/blackfin/include/asm/bfin_can.h
>> +++ /dev/null
>> @@ -1,728 +0,0 @@
>> -/*
>> - * bfin_can.h - interface to Blackfin CANs
>> - *
>> - * Copyright 2004-2009 Analog Devices Inc.
>> - *
>> - * Licensed under the GPL-2 or later.
>> - */
>> -
>> -#ifndef __ASM_BFIN_CAN_H__
>> -#define __ASM_BFIN_CAN_H__
>> -
>> -/*
>> - * transmit and receive channels
>> - */
>> -#define TRANSMIT_CHL24
>> -#define RECEIVE_STD_CHL 0
>> -#define RECEIVE_EXT_CHL 4
>> -#define RECEIVE_RTR_CHL 8
>> -#define RECEIVE_EXT_RTR_CHL 12
>> -#define MAX_CHL_NUMBER 32
>> -
>> -/*
>> - * All Blackfin system MMRs are padded to 32bits even if the register
>> - * itself is only 16bits. So use a helper macro to streamline this.
>> - */
>> -#define __BFP(m) u16 m; u16 __pad_##m
>> -
>> -/*
>> - * bfin can registers layout
>> - */
>> -struct bfin_can_mask_regs {
>> -__BFP(aml);
>> -__BFP(amh);
>> -};
>> -
>> -struct bfin_can_channel_regs {
>> -/* data[0,2,4,6] -> data{0,1,2,3} while data[1,3,5,7] is padding */
>> -u16 data[8];
>> -__BFP(dlc);
>> -__BFP(tsv);
>> -__BFP(id0);
>> -__BFP(id1);
>> -};
>> -
>> -struct bfin_can_regs {
>> -/*
>> - * global control and status registers
>> - */
>> -__BFP(mc1); /* offset 0x00 */
>> -__BFP(md1); /* offset 0x04 */
>> -__BFP(trs1); /* offset 0x08 */
>> -__BFP(trr1); /* offset 0x0c */
>> -__BFP(ta1); /* offset 0x10 */
>> -__BFP(aa1); /* offset 0x14 */
>> -__BFP(rmp1); /* offset 0x18 */
>> -__BFP(rml1); /* offset 0x1c */
>> -__BFP(mbtif1);/* offset 0x20 */
>> -__BFP(mbrif1);/* offset 0x24 */
>> -__BFP(mbim1); /* offset 0x28 */
>> -__BFP(rfh1); /* offset 0x2c */
>> -__BFP(opss1); /* offset 0x30 */
>> -u32 __pad1[3];
>> -__BFP(mc2); /* offset 0x40 */
>> -__BFP(md2); /* offset 0x44 */
>> -__BFP(trs2); /* offset 0x48 */
>> -__BFP(trr2); /* offset 0x4c */
>> -__BFP(ta2); /* offset 0x50 */
>> -__BFP(aa2); /* offset 0x54 */
>> -__BFP(rmp2); /* offset 0x58 */
>> -__BFP(rml2); /* offset 0x5c */
>> -__BFP(mbtif2);/* offset 0x60 */
>> -__BFP(mbrif2);/* offset 0x64 */
>> -__BFP(mbim2); /* offset 0x68 */
>> -__BFP(rfh2); /* offset 0x6c */
>> -__BFP(opss2); /* offset 0x70 */
>> -u32 __pad2[3];
>> -__BFP(clock); /* offset 0x80 */
>> -__BFP(timing);/* offset 0x84 */
>> -__BFP(debug); /* offset 0x88 */
>> -__BFP(status);/* offset 0x8c */
>> -__BFP(cec); /* offset 0x90 */
>> -__BFP(gis); /* offset 0x94 */
>> -__BFP(gim); /* offset 0x98 */
>> -__BFP(gif); /* offset 0x9c */
>> -__BFP(control); /* offset 0xa0 */
>> -__BFP(intr); /* offset 0xa4 */
>> -__BFP(version); /* offset 0xa8 */
>> -__BFP(mbtd); /* offset 0xac */
>> -__BFP(ewr); /* offset 0xb0 */
>> -__BFP(esr); /* offset 0xb4 */
Re: [LKP] [ftrace] fef5aeeee9e: -27.2% boot-slabinfo.num_objs
On Tue, 2014-12-23 at 08:32 -0500, Steven Rostedt wrote:
> On Tue, 23 Dec 2014 11:10:17 +0800
> Huang Ying wrote:
>
> > FYI, we noticed the below changes on
> >
> > commit fef5a9e3717e7aea991a7ae9ff6a7a2d4c85 ("ftrace: Replace
> > tramp_hash with old_*_hash to save space")
> >
> >
> > testbox/testcase/testparams: vm-kbuild-4G/boot/1
> >
> > e1effa0144a1ddf5 fef5a9e3717e7aea991a7a
> > --
> > %stddev %change %stddev
> > \ |\
> > 437752 ± 0% -27.2% 318545 ± 0% boot-slabinfo.num_objs
> >
> > vm-kbuild-4G: qemu-system-x86_64 -enable-kvm
> > Memory: 4G
>
> I have no idea what this test does. Is this good or bad? Is that -27.2%
> a performance regression, or memory regression?
IMO, it is good. Memory usage is reduced.
Best Regards,
Huang, Ying
> -- Steve
>
>
> >
> >
> >
> >boot-slabinfo.num_objs
> >
> > 44
> > *+*--*-*-*--**-*-*--**-*--*-*-*--*-+
> > | *.* *. *.*..*
> > |
> > 42 ++
> > |
> > |
> > |
> > 40 ++
> > |
> > |
> > |
> > 38 ++
> > |
> > |
> > |
> > 36 ++
> > |
> > |
> > |
> > 34 ++
> > |
> > |
> > |
> > 32 O+O O O O O O O O O O O OO O OO O O O O O O O O O
> > O
> > | OO O
> > |
> > 30
> > ++-+
> >
> > [*] bisect-good sample
> > [O] bisect-bad sample
> >
> > To reproduce:
> >
> > apt-get install ruby ruby-oj
> > git clone
> > git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
> > cd lkp-tests
> > bin/setup-local job.yaml # the job file attached in this email
> > bin/run-local job.yaml
> >
> >
> > Disclaimer:
> > Results have been estimated based on internal Intel analysis and are
> > provided
> > for informational purposes only. Any difference in system hardware or
> > software
> > design or configuration may affect actual performance.
> >
> >
> > Thanks,
> > Huang, Ying
> >
>
--
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: panic at rb_next when do pick_next_task_fair because of rb_leftmost is NULL
one more info as following before crash.
[83321.794602] c1 230 (DispSync) BUG: Bad rss-counter state
mm:ec376200 idx:0 val:2497
[83321.795281] c0 2084 (v.airplayserver) Unable to handle kernel NULL
pointer dereference at virtual address 0008
2014-12-29 9:56 GMT+08:00 Neil Zhang :
> Does anyone ever encountered it?
> Please give your help if any.
> Thanks in advanced!
>
> Best Regards,
> Neil Zhang
>
>
> 2014-12-26 17:37 GMT+08:00 Neil Zhang :
>> Hi All,
>> I encountered the following crash in 3.10.24.
>>
>> The panic log is as following.
>> The strange thing is that the nr_running change to NULL after pass the
>> check in the beginning of pick_next_task_fair.
>> So it seems there are race condition in the code.
>> Seems no related patch to fix it in the mainline.
>> Does anyone can help it?
>>
>> struct rq {
>> lock = {
>> raw_lock = {
>> {
>> slock = 1463113524,
>> tickets = {
>> owner = 22324,
>> next = 22325
>> }
>> }
>> }
>> },
>> nr_running = 0,
>> cpu_load = {0, 0, 3, 33, 72},
>> last_load_update_tick = 83021764,
>> nohz_stamp = 0,
>> nohz_flags = 1,
>> skip_clock_update = 0,
>> nr_last_stamp = 83321795255303,
>> nr_running_integral = 54283347762368512,
>> ave_seqcnt = {
>> sequence = 690446180
>> },
>> load = {
>> weight = 0,
>> inv_weight = 0
>> },
>> nr_load_updates = 51751174,
>> nr_switches = 290795987,
>> cfs = {
>> load = {
>> weight = 0,
>> inv_weight = 0
>> },
>> nr_running = 0,
>> h_nr_running = 0,
>> exec_clock = 17025953367624,
>> min_vruntime = 125082978146967,
>> min_vruntime_copy = 125082978146967,
>> tasks_timeline = {
>> rb_node = 0x0
>> },
>> rb_leftmost = 0x0,
>> curr = 0x0,
>> next = 0x0,
>> last = 0x0,
>> skip = 0x0,
>> nr_spread_over = 57488,
>> runnable_load_avg = 0,
>>
>> [83321.795281] c0 2084 (v.airplayserver) Unable to handle kernel NULL
>> pointer dereference at virtual address 0008
>> [83321.795286] c0 2084 (v.airplayserver) pgd = ea858000
>> [83321.795293] c0 2084 (v.airplayserver) [0008] *pgd=
>> [83321.795306] c0 2084 (v.airplayserver) Internal error: Oops: 205
>> [#1] PREEMPT SMP ARM
>> [83321.795315] c0 2084 (v.airplayserver) Modules linked in:
>> [83321.795324] c0 2084 (v.airplayserver) CPU: 0 PID: 2084 Comm:
>> v.airplayserver Not tainted 3.10.24-gc7b472f #1
>> [83321.795329] c0 2084 (v.airplayserver) task: ce1f1ac0 ti: ce156000
>> task.ti: ce156000
>> [83321.795349] c0 2084 (v.airplayserver) PC is at rb_next+0x0/0x60
>> [83321.795363] c0 2084 (v.airplayserver) LR is at
>> pick_next_task_fair+0x10c/0x138
>> [83321.795368] c0 2084 (v.airplayserver) pc : [] lr :
>> [] psr: 60060093
>> sp : ce157e18 ip : fp : ce157edc
>> [83321.795371] c0 2084 (v.airplayserver) r10: c54474c0 r9 : c0c644c0
>> r8 : ce157f20
>> [83321.795376] c0 2084 (v.airplayserver) r7 : c54474c0 r6 :
>> r5 : r4 : c5447518
>> [83321.795380] c0 2084 (v.airplayserver) r3 : c0097294 r2 : c54478f8
>> r1 : r0 : 0008
>> [83321.795388] c0 2084 (v.airplayserver) Flags: nZCv IRQs off FIQs on
>> Mode SVC_32 ISA ARM Segment user
>> [83321.795392] c0 2084 (v.airplayserver) Control: 30c5387d Table:
>> aa858000 DAC: fffd
>> [83321.795396] c0 2084 (v.airplayserver)
>> PC: 0xc02c2270:
>> [83321.795419] c0 2084 (v.airplayserver) 2270 1a01 ea04
>> e1a3 e5903004 e353 1afb e12fff1e e12fff1e
>> [83321.795439] c0 2084 (v.airplayserver) 2290 e1a03001 e5901000
>> e3d11003 05823000 0a03 e5912008 e152 05813008
>> [83321.795461] c0 2084 (v.airplayserver) 22b0 15813004 e5902008
>> e352 15921000 12011001 11831001 15821000 e5902004
>> [83321.795483] c0 2084 (v.airplayserver) 22d0 e352 15921000
>> 12011001 11831001 15821000 e897 e8830007 e12fff1e
>> [83321.795504] c0 2084 (v.airplayserver) 22f0 e5902000 e152
>> 0a12 e5903004 e353 1a01 ea06 e1a03002
>> [83321.795526] c0 2084 (v.airplayserver) 2310 e5932008 e352
>> 1afb e1a3 e12fff1e e5932000 e3d23003 0afa
>> [83321.795546] c0 2084 (v.airplayserver) 2330 e5932004 e152
>> e1a3 0af8 e1a3 e12fff1e e3a03000 eaf2
>> [83321.795568] c0 2084 (v.airplayserver) 2350 e5902000 e152
>> 0a12 e5903008 e353 1a01 ea06 e1a03002
>> [83321.795572] c0 2084 (v.airplayserver)
>> LR: 0xc0097320:
>> [83321.795592] c0 2084 (v.airplayserver) 7320 e5954128 e354
>> 1ae1 e59f3090 e2455038 e5933000 e3130080 0a13
>> [83321.795612] c0 2084 (v.airplayserver) 7340 e59734e4 e283101f
>> e353 e203201f b1a03001 e59f106c e1a032c3 e5911000
>> [83321.795635] c0 2084 (v.airplayserver) 7360 e7913103 e1a03233
>> e3130001 0a07 e597355c e5933000 e5933018 e353
>> [83321.795657] c0 2084 (v.airplayserver) 7380 0a02 e1a7
>> e1a01005 ebfffe2a e1a5 e8bd80f8 e2860008 eb08abd3
>> [83321.795681] c0 2084 (v.airplayserver) 73a0 e350 0ac9
>> e2405008 e1a01006 e1a5 eb0d e350 c1a05006
>> [83321.795702] c0 2084 (v.airplayserver) 73c0 eac2 c0c9b4b4
>> c08945bc e92d00f0 e52de004 e8bd4000 e3a02020 e3a03000
>> [8
[PATCH] staging: rtl8723au: changes stop ap mode to use reset function
Changes stop_ap_mode23a() to use rtw_reset_securitypriv23a. This makes the code cleaner and fixes two checkpatch.pl errors, one line over 80 characters, and one spacing issue. Signed-off-by: Matthew Emerson --- drivers/staging/rtl8723au/core/rtw_ap.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/staging/rtl8723au/core/rtw_ap.c b/drivers/staging/rtl8723au/core/rtw_ap.c index e394d12c36b0..510ee212496f 100644 --- a/drivers/staging/rtl8723au/core/rtw_ap.c +++ b/drivers/staging/rtl8723au/core/rtw_ap.c @@ -1870,10 +1870,8 @@ void stop_ap_mode23a(struct rtw_adapter *padapter) pmlmepriv->update_bcn = false; pmlmeext->bstart_bss = false; - /* reset and init security priv , this can refine with rtw_reset_securitypriv23a */ - memset((unsigned char *)&padapter->securitypriv, 0, sizeof (struct security_priv)); - padapter->securitypriv.ndisauthtype = Ndis802_11AuthModeOpen; - padapter->securitypriv.ndisencryptstatus = Ndis802_11WEPDisabled; + /* reset and init security priv */ + rtw_reset_securitypriv23a(padapter); /* for ACL */ spin_lock_bh(&pacl_node_q->lock); -- 2.0.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] move exit_task_work() before exit_fs().
On Mon, Dec 29, 2014 at 01:33:37AM +, Ma, Xindong wrote: > > On Fri, Dec 26, 2014 at 03:45:25PM +0800, Leon Ma wrote: > > > We encountered following panic. The scenario is the process is exiting > > > and executing its task work. When closing dev node, the driver > > > triggers a firmware reload according to device status. Because task->fs is > > set to NULL in exit_fs(), panic happens. > > > Task work is a common interface, we should not limite the resource the > > user will utilize. > > > > Fix your driver. Forget ->fs being NULL; what will happen if your process > > is > > chrooted? > Thanks, But I'm not clear what is the limitation added to chroot env? ??? How about "the pathname of firmware apparently will be looked up inside the chroot"? Look, this is completely broken - you *can't* assume anything about the fs context in which ->release() will be run, period. It's not guaranteed to have anything in common with the environment in which the file had been opened, BTW - there might literally be not a single filesystem in common for both. This "reload firmware in ->release()" is absolutely braindead. The fact that it as much as dereferences current->fs demonstrates that it's broken. Don't do that. -- 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: panic at rb_next when do pick_next_task_fair because of rb_leftmost is NULL
Does anyone ever encountered it?
Please give your help if any.
Thanks in advanced!
Best Regards,
Neil Zhang
2014-12-26 17:37 GMT+08:00 Neil Zhang :
> Hi All,
> I encountered the following crash in 3.10.24.
>
> The panic log is as following.
> The strange thing is that the nr_running change to NULL after pass the
> check in the beginning of pick_next_task_fair.
> So it seems there are race condition in the code.
> Seems no related patch to fix it in the mainline.
> Does anyone can help it?
>
> struct rq {
> lock = {
> raw_lock = {
> {
> slock = 1463113524,
> tickets = {
> owner = 22324,
> next = 22325
> }
> }
> }
> },
> nr_running = 0,
> cpu_load = {0, 0, 3, 33, 72},
> last_load_update_tick = 83021764,
> nohz_stamp = 0,
> nohz_flags = 1,
> skip_clock_update = 0,
> nr_last_stamp = 83321795255303,
> nr_running_integral = 54283347762368512,
> ave_seqcnt = {
> sequence = 690446180
> },
> load = {
> weight = 0,
> inv_weight = 0
> },
> nr_load_updates = 51751174,
> nr_switches = 290795987,
> cfs = {
> load = {
> weight = 0,
> inv_weight = 0
> },
> nr_running = 0,
> h_nr_running = 0,
> exec_clock = 17025953367624,
> min_vruntime = 125082978146967,
> min_vruntime_copy = 125082978146967,
> tasks_timeline = {
> rb_node = 0x0
> },
> rb_leftmost = 0x0,
> curr = 0x0,
> next = 0x0,
> last = 0x0,
> skip = 0x0,
> nr_spread_over = 57488,
> runnable_load_avg = 0,
>
> [83321.795281] c0 2084 (v.airplayserver) Unable to handle kernel NULL
> pointer dereference at virtual address 0008
> [83321.795286] c0 2084 (v.airplayserver) pgd = ea858000
> [83321.795293] c0 2084 (v.airplayserver) [0008] *pgd=
> [83321.795306] c0 2084 (v.airplayserver) Internal error: Oops: 205
> [#1] PREEMPT SMP ARM
> [83321.795315] c0 2084 (v.airplayserver) Modules linked in:
> [83321.795324] c0 2084 (v.airplayserver) CPU: 0 PID: 2084 Comm:
> v.airplayserver Not tainted 3.10.24-gc7b472f #1
> [83321.795329] c0 2084 (v.airplayserver) task: ce1f1ac0 ti: ce156000
> task.ti: ce156000
> [83321.795349] c0 2084 (v.airplayserver) PC is at rb_next+0x0/0x60
> [83321.795363] c0 2084 (v.airplayserver) LR is at
> pick_next_task_fair+0x10c/0x138
> [83321.795368] c0 2084 (v.airplayserver) pc : [] lr :
> [] psr: 60060093
> sp : ce157e18 ip : fp : ce157edc
> [83321.795371] c0 2084 (v.airplayserver) r10: c54474c0 r9 : c0c644c0
> r8 : ce157f20
> [83321.795376] c0 2084 (v.airplayserver) r7 : c54474c0 r6 :
> r5 : r4 : c5447518
> [83321.795380] c0 2084 (v.airplayserver) r3 : c0097294 r2 : c54478f8
> r1 : r0 : 0008
> [83321.795388] c0 2084 (v.airplayserver) Flags: nZCv IRQs off FIQs on
> Mode SVC_32 ISA ARM Segment user
> [83321.795392] c0 2084 (v.airplayserver) Control: 30c5387d Table:
> aa858000 DAC: fffd
> [83321.795396] c0 2084 (v.airplayserver)
> PC: 0xc02c2270:
> [83321.795419] c0 2084 (v.airplayserver) 2270 1a01 ea04
> e1a3 e5903004 e353 1afb e12fff1e e12fff1e
> [83321.795439] c0 2084 (v.airplayserver) 2290 e1a03001 e5901000
> e3d11003 05823000 0a03 e5912008 e152 05813008
> [83321.795461] c0 2084 (v.airplayserver) 22b0 15813004 e5902008
> e352 15921000 12011001 11831001 15821000 e5902004
> [83321.795483] c0 2084 (v.airplayserver) 22d0 e352 15921000
> 12011001 11831001 15821000 e897 e8830007 e12fff1e
> [83321.795504] c0 2084 (v.airplayserver) 22f0 e5902000 e152
> 0a12 e5903004 e353 1a01 ea06 e1a03002
> [83321.795526] c0 2084 (v.airplayserver) 2310 e5932008 e352
> 1afb e1a3 e12fff1e e5932000 e3d23003 0afa
> [83321.795546] c0 2084 (v.airplayserver) 2330 e5932004 e152
> e1a3 0af8 e1a3 e12fff1e e3a03000 eaf2
> [83321.795568] c0 2084 (v.airplayserver) 2350 e5902000 e152
> 0a12 e5903008 e353 1a01 ea06 e1a03002
> [83321.795572] c0 2084 (v.airplayserver)
> LR: 0xc0097320:
> [83321.795592] c0 2084 (v.airplayserver) 7320 e5954128 e354
> 1ae1 e59f3090 e2455038 e5933000 e3130080 0a13
> [83321.795612] c0 2084 (v.airplayserver) 7340 e59734e4 e283101f
> e353 e203201f b1a03001 e59f106c e1a032c3 e5911000
> [83321.795635] c0 2084 (v.airplayserver) 7360 e7913103 e1a03233
> e3130001 0a07 e597355c e5933000 e5933018 e353
> [83321.795657] c0 2084 (v.airplayserver) 7380 0a02 e1a7
> e1a01005 ebfffe2a e1a5 e8bd80f8 e2860008 eb08abd3
> [83321.795681] c0 2084 (v.airplayserver) 73a0 e350 0ac9
> e2405008 e1a01006 e1a5 eb0d e350 c1a05006
> [83321.795702] c0 2084 (v.airplayserver) 73c0 eac2 c0c9b4b4
> c08945bc e92d00f0 e52de004 e8bd4000 e3a02020 e3a03000
> [83321.795724] c0 2084 (v.airplayserver) 73e0 e1530001 0152
> 3a04 e59f30ec e0830100 e59000e4 e8bd00f0 e12fff1e
> [83321.795746] c0 2084 (v.airplayserver) 7400 e351 03500f56
> 8a2e e1a04000 e1a05001 e3e0601f e3e07000 e3a0c000
> [83321.795751] c0 2084 (v.airplayserver)
> SP: 0xce157d98:
> [83321.795771] c0 2084 (v.airplayserver) 7d98 ed711dc0
> c54474c0 000
From Mr. Natan Pang...
Hello Dear, I am Mr. Natan Pang a banker, I have emailed you earlier on without any response from you. In my first email I mentioned about our deceased customer a citizen of your country whose relatives my Bank cannot locate to claim his estate. I got your address from online directory service and decided to write you as I cannot achieve this opportunity alone without the support of a foreigner. I am asking for your consent so that I can present you to my Bank Management as the next of kin to the late customer account proceeds value ($4,000,000)(Four Million United State Dollars) to be transferred into your account for our mutual benefit At the successful transfer of this fund, we shall share the fund on a pro rata based percentage [50% - 50%]. I am compelled to do this because I do not want my Bank to take over the ownership of this fund. If you are interested and in agreement with me, get back to me quickly and I will send to you all the information you may need to proceed without coming to the Bank, and be rest assured that it is risk free project. I look forward to your reply. Yours faithfully, Mr. Natan Pang natan_p...@yahoo.co.uk -- 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] move exit_task_work() before exit_fs().
> On 12/28/2014 07:58 PM, Ma, Xindong wrote: > >> > >> On 12/26, Leon Ma wrote: > >>> > >>> We encountered following panic. The scenario is the process is > >>> exiting and executing its task work. When closing dev node, the > >>> driver triggers a firmware reload according to device status. > >>> Because task->fs is > >> set to NULL in exit_fs(), panic happens. > >> > >> I think this should be fixed somewhere else... > > Yes, for this panic, I also think driver is not perfect and need a fix. But > kernel should not add the limitation like this... > >> > >>> Task work is a common interface, we should not limite the resource > >>> the > >> user will utilize. > >> > >> Exactly. And note that with this patch exit_mm()..disassociate_ctty() > >> paths can't use task works. > > I don't get this. Currently disassociate_ctty() is also called after > > exit_mm() > and exit_task_work(). My patch didn't change this. > > ?? > > 742- if (group_dead) > 743: disassociate_ctty(1); > 744- exit_task_namespaces(tsk); > 745- exit_task_work(tsk); > 746- exit_thread(); Sorry, I was checking the old source code when applying this mail. I did a check on latest code, and did not find disassociate_ctty() was using task work. So why this matters? > > >> Not to mention that this patch moves exit_files() up, even before > >> exit_mm(), without any explanation. > > Moving exit_files() up is because exit_files() closes files and add tasks to > task works. > >> > >> Add Al. May be we can move exit_fs() down after exit_task_work(), I > >> dunno, but to me it would be better to change the driver. > >> > > I'm OK with this suggestion to fix this issue. I'm not sure whether in the > future task work users will access other resources and expose other issues. > >
RE: [PATCH] move exit_task_work() before exit_fs().
> On Fri, Dec 26, 2014 at 03:45:25PM +0800, Leon Ma wrote: > > We encountered following panic. The scenario is the process is exiting > > and executing its task work. When closing dev node, the driver > > triggers a firmware reload according to device status. Because task->fs is > set to NULL in exit_fs(), panic happens. > > Task work is a common interface, we should not limite the resource the > user will utilize. > > Fix your driver. Forget ->fs being NULL; what will happen if your process is > chrooted? Thanks, But I'm not clear what is the limitation added to chroot env? -- 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.2 12/27] x86, kvm: Clear paravirt_enabled on KVM guests for espfix32's benefit
3.2.66-rc1 review patch. If anyone has any objections, please let me know.
--
From: Andy Lutomirski
commit 29fa6825463c97e5157284db80107d1bfac5d77b upstream.
paravirt_enabled has the following effects:
- Disables the F00F bug workaround warning. There is no F00F bug
workaround any more because Linux's standard IDT handling already
works around the F00F bug, but the warning still exists. This
is only cosmetic, and, in any event, there is no such thing as
KVM on a CPU with the F00F bug.
- Disables 32-bit APM BIOS detection. On a KVM paravirt system,
there should be no APM BIOS anyway.
- Disables tboot. I think that the tboot code should check the
CPUID hypervisor bit directly if it matters.
- paravirt_enabled disables espfix32. espfix32 should *not* be
disabled under KVM paravirt.
The last point is the purpose of this patch. It fixes a leak of the
high 16 bits of the kernel stack address on 32-bit KVM paravirt
guests. Fixes CVE-2014-8134.
Suggested-by: Konrad Rzeszutek Wilk
Signed-off-by: Andy Lutomirski
Signed-off-by: Paolo Bonzini
Signed-off-by: Ben Hutchings
---
arch/x86/kernel/kvm.c | 9 -
arch/x86/kernel/kvmclock.c | 1 -
2 files changed, 8 insertions(+), 2 deletions(-)
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -419,7 +419,14 @@ static void kvm_leave_lazy_mmu(void)
static void __init paravirt_ops_setup(void)
{
pv_info.name = "KVM";
- pv_info.paravirt_enabled = 1;
+
+ /*
+* KVM isn't paravirt in the sense of paravirt_enabled. A KVM
+* guest kernel works like a bare metal kernel with additional
+* features, and paravirt_enabled is about features that are
+* missing.
+*/
+ pv_info.paravirt_enabled = 0;
if (kvm_para_has_feature(KVM_FEATURE_NOP_IO_DELAY))
pv_cpu_ops.io_delay = kvm_io_delay;
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -203,7 +203,6 @@ void __init kvmclock_init(void)
#endif
kvm_get_preset_lpj();
clocksource_register_hz(&kvm_clock, NSEC_PER_SEC);
- pv_info.paravirt_enabled = 1;
pv_info.name = "KVM";
if (kvm_para_has_feature(KVM_FEATURE_CLOCKSOURCE_STABLE_BIT))
--
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.2 16/27] s390,time: revert direct ktime path for s390 clockevent device
3.2.66-rc1 review patch. If anyone has any objections, please let me know.
--
From: Martin Schwidefsky
commit 8adbf78ec4839c1dc4ff20c9a1f332a7bc99e6e6 upstream.
Git commit 4f37a68cdaf6dea833cfdded2a3e0c47c0f006da
"s390: Use direct ktime path for s390 clockevent device" makes use
of the CLOCK_EVT_FEAT_KTIME clockevent option to avoid the delta
calculation with ktime_get() in clockevents_program_event and the
get_tod_clock() in s390_next_event. This is based on the assumption
that the difference between the internal ktime and the hardware
clock is reflected in the wall_to_monotonic delta. But this is not
true, the ntp corrections are applied via changes to the tk->mult
multiplier and this is not reflected in wall_to_monotonic.
In theory this could be solved by using the raw monotonic clock
but it is simpler to switch back to the standard clock delta
calculation.
Signed-off-by: Martin Schwidefsky
[bwh: Backported to 3.2: s/get_tod_clock()/get_clock()/]
Signed-off-by: Ben Hutchings
---
arch/s390/kernel/time.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
--- a/arch/s390/kernel/time.c
+++ b/arch/s390/kernel/time.c
@@ -110,20 +110,10 @@ static void fixup_clock_comparator(unsig
set_clock_comparator(S390_lowcore.clock_comparator);
}
-static int s390_next_ktime(ktime_t expires,
+static int s390_next_event(unsigned long delta,
struct clock_event_device *evt)
{
- struct timespec ts;
- u64 nsecs;
-
- ts.tv_sec = ts.tv_nsec = 0;
- monotonic_to_bootbased(&ts);
- nsecs = ktime_to_ns(ktime_add(timespec_to_ktime(ts), expires));
- do_div(nsecs, 125);
- S390_lowcore.clock_comparator = sched_clock_base_cc + (nsecs << 9);
- /* Program the maximum value if we have an overflow (== year 2042) */
- if (unlikely(S390_lowcore.clock_comparator < sched_clock_base_cc))
- S390_lowcore.clock_comparator = -1ULL;
+ S390_lowcore.clock_comparator = get_clock() + delta;
set_clock_comparator(S390_lowcore.clock_comparator);
return 0;
}
@@ -148,15 +138,14 @@ void init_cpu_timer(void)
cpu = smp_processor_id();
cd = &per_cpu(comparators, cpu);
cd->name= "comparator";
- cd->features= CLOCK_EVT_FEAT_ONESHOT |
- CLOCK_EVT_FEAT_KTIME;
+ cd->features= CLOCK_EVT_FEAT_ONESHOT;
cd->mult= 16777;
cd->shift = 12;
cd->min_delta_ns= 1;
cd->max_delta_ns= LONG_MAX;
cd->rating = 400;
cd->cpumask = cpumask_of(cpu);
- cd->set_next_ktime = s390_next_ktime;
+ cd->set_next_event = s390_next_event;
cd->set_mode= s390_set_mode;
clockevents_register_device(cd);
--
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.2 17/27] drm: fix DRM_IOCTL_MODE_GETFB handle-leak
3.2.66-rc1 review patch. If anyone has any objections, please let me know.
--
From: David Herrmann
commit 101b96f32956ee99bf1468afaf572b88cda9f88b upstream.
DRM_IOCTL_MODE_GETFB is used to retrieve information about a given
framebuffer ID. It is a read-only helper and was thus declassified for
unprivileged access in:
commit a14b1b42477c5ef089fcda88cbaae50d979eb8f9
Author: Mandeep Singh Baines
Date: Fri Jan 20 12:11:16 2012 -0800
drm: remove master fd restriction on mode setting getters
However, alongside width, height and stride information,
DRM_IOCTL_MODE_GETFB also passes back a handle to the underlying buffer of
the framebuffer. This handle allows users to mmap() it and read or write
into it. Obviously, this should be restricted to DRM-Master.
With the current setup, *any* process with access to /dev/dri/card0 (which
means any process with access to hardware-accelerated rendering) can
access the current screen framebuffer and modify it ad libitum.
For backwards-compatibility reasons we want to keep the
DRM_IOCTL_MODE_GETFB call unprivileged. Besides, it provides quite useful
information regarding screen setup. So we simply test whether the caller
is the current DRM-Master and if not, we return 0 as handle, which is
always invalid. A following DRM_IOCTL_GEM_CLOSE on this handle will fail
with EINVAL, but we accept this. Users shouldn't test for errors during
GEM_CLOSE, anyway. And it is still better as a failing MODE_GETFB call.
v2: add capable(CAP_SYS_ADMIN) check for compatibility with i-g-t
Signed-off-by: David Herrmann
Reviewed-by: Chris Wilson
Signed-off-by: Dave Airlie
[bwh: Backported to 3.2:
- drm_framebuffer_funcs::create_handle must be non-null
- Adjust context, indentation]
Signed-off-by: Ben Hutchings
---
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1815,7 +1815,17 @@ int drm_mode_getfb(struct drm_device *de
r->depth = fb->depth;
r->bpp = fb->bits_per_pixel;
r->pitch = fb->pitch;
- fb->funcs->create_handle(fb, file_priv, &r->handle);
+ if (file_priv->is_master || capable(CAP_SYS_ADMIN)) {
+ ret = fb->funcs->create_handle(fb, file_priv, &r->handle);
+ } else {
+ /* GET_FB() is an unprivileged ioctl so we must not
+* return a buffer-handle to non-master processes! For
+* backwards-compatibility reasons, we cannot make
+* GET_FB() privileged, so just return an invalid handle
+* for non-masters. */
+ r->handle = 0;
+ ret = 0;
+ }
out:
mutex_unlock(&dev->mode_config.mutex);
--
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: [REGRESSION][x86] Commit f5b2831d65 cause boot failure in VMware ESXi 5.1 guest
Original Message Subject: Re: [REGRESSION][x86] Commit f5b2831d65 cause boot failure in VMware ESXi 5.1 guest From: Juergen Gross To: Qu Wenruo Date: 2014年12月27日 21:51 On 12/26/2014 02:57 AM, Qu Wenruo wrote: Hi all, When testing v3.19-rc1 kernel(in fact, try to test), the kernel itself fail to boot on VMware ESXi 5.1 guest. The boot failure is quite easy to describe, only one line is output: "Probing EDD (edd=off to disable)...ok" No other output(including warning/bug_on/backtrace or whatever) and the guest just hangs. It's OK on v3.18, so it's a regression. Bisect points to the following commit: commit f5b2831d654167d77da8afbef4d2584897b12d0c Author: Juergen Gross Date: Mon Nov 3 14:02:02 2014 +0100 x86: Respect PAT bit when copying pte values between large and normal pages The PAT bit in the ptes is not moved to the correct position when copying page protection attributes between entries of different sized pages. Translate the ptes according to their page size. I have also created the kernel BZ report: https://bugzilla.kernel.org/show_bug.cgi?id=90321 Hopes this can be resolved in next rc. As the same issue has been reported with VMWare workstation which was related to an error in the PAT MSR emulation of VMWare, I guess this will be the same problem. I've already sent a patch. You should be able to boot with the "nopat" kernel option. Juergen Thanks for the explanation. Again the closed source blob to blame. Anyway, the nopat option works. Great thanks Qu -- 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.2 25/27] drivers/net: macvtap and tun depend on INET
3.2.66-rc1 review patch. If anyone has any objections, please let me know.
--
From: Ben Hutchings
commit de11b0e8c569b96c2cf6a811e3805b7aeef498a3 upstream.
These drivers now call ipv6_proxy_select_ident(), which is defined
only if CONFIG_INET is enabled. However, they have really depended
on CONFIG_INET for as long as they have allowed sending GSO packets
from userland.
Reported-by: kbuild test robot
Signed-off-by: Ben Hutchings
Fixes: f43798c27684 ("tun: Allow GSO using virtio_net_hdr")
Fixes: b9fb9ee07e67 ("macvtap: add GSO/csum offload support")
Fixes: 5188cd44c55d ("drivers/net, ipv6: Select IPv6 fragment idents for virtio
UFO packets")
Signed-off-by: David S. Miller
---
drivers/net/Kconfig | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -143,6 +143,7 @@ config MACVLAN
config MACVTAP
tristate "MAC-VLAN based tap driver (EXPERIMENTAL)"
depends on MACVLAN
+ depends on INET
help
This adds a specialized tap character device driver that is based
on the MAC-VLAN network interface, called macvtap. A macvtap device
@@ -195,6 +196,7 @@ config RIONET_RX_SIZE
config TUN
tristate "Universal TUN/TAP device driver support"
+ depends on INET
select CRC32
---help---
TUN/TAP provides packet reception and transmission for user space
--
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.2 27/27] x86: kvm: use alternatives for VMCALL vs. VMMCALL if kernel text is read-only
3.2.66-rc1 review patch. If anyone has any objections, please let me know.
--
From: Paolo Bonzini
commit c1118b3602c2329671ad5ec8bdf8e374323d6343 upstream.
On x86_64, kernel text mappings are mapped read-only with CONFIG_DEBUG_RODATA.
In that case, KVM will fail to patch VMCALL instructions to VMMCALL
as required on AMD processors.
The failure mode is currently a divide-by-zero exception, which obviously
is a KVM bug that has to be fixed. However, picking the right instruction
between VMCALL and VMMCALL will be faster and will help if you cannot upgrade
the hypervisor.
Reported-by: Chris Webb
Tested-by: Chris Webb
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Acked-by: Borislav Petkov
Signed-off-by: Paolo Bonzini
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings
---
arch/x86/include/asm/cpufeature.h | 1 +
arch/x86/include/asm/kvm_para.h | 10 --
arch/x86/kernel/cpu/amd.c | 7 +++
3 files changed, 16 insertions(+), 2 deletions(-)
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -193,6 +193,7 @@
#define X86_FEATURE_DECODEASSISTS (8*32+12) /* AMD Decode Assists support */
#define X86_FEATURE_PAUSEFILTER (8*32+13) /* AMD filtered pause intercept */
#define X86_FEATURE_PFTHRESHOLD (8*32+14) /* AMD pause filter threshold */
+#define X86_FEATURE_VMMCALL ( 8*32+15) /* Prefer vmmcall to vmcall */
/* Intel-defined CPU features, CPUID level 0x0007:0 (ebx), word 9 */
--- a/arch/x86/include/asm/kvm_para.h
+++ b/arch/x86/include/asm/kvm_para.h
@@ -91,15 +91,21 @@ struct kvm_vcpu_pv_apf_data {
#ifdef __KERNEL__
#include
+#include
extern void kvmclock_init(void);
extern int kvm_register_clock(char *txt);
-/* This instruction is vmcall. On non-VT architectures, it will generate a
- * trap that we will then rewrite to the appropriate instruction.
+#ifdef CONFIG_DEBUG_RODATA
+#define KVM_HYPERCALL \
+ALTERNATIVE(".byte 0x0f,0x01,0xc1", ".byte 0x0f,0x01,0xd9",
X86_FEATURE_VMMCALL)
+#else
+/* On AMD processors, vmcall will generate a trap that we will
+ * then rewrite to the appropriate instruction.
*/
#define KVM_HYPERCALL ".byte 0x0f,0x01,0xc1"
+#endif
/* For KVM hypercalls, a three-byte sequence of either the vmrun or the vmmrun
* instruction. The hypervisor may replace it with something else but only the
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -469,6 +469,13 @@ static void __cpuinit early_init_amd(str
set_cpu_cap(c, X86_FEATURE_EXTD_APICID);
}
#endif
+
+ /*
+* This is only needed to tell the kernel whether to use VMCALL
+* and VMMCALL. VMMCALL is never executed except under virt, so
+* we can set it unconditionally.
+*/
+ set_cpu_cap(c, X86_FEATURE_VMMCALL);
}
static void __cpuinit init_amd(struct cpuinfo_x86 *c)
--
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.2 15/27] ext4: make orphan functions be no-op in no-journal mode
3.2.66-rc1 review patch. If anyone has any objections, please let me know.
--
From: Anatol Pomozov
commit c9b92530a723ac5ef8e352885a1862b18f31b2f5 upstream.
Instead of checking whether the handle is valid, we check if journal
is enabled. This avoids taking the s_orphan_lock mutex in all cases
when there is no journal in use, including the error paths where
ext4_orphan_del() is called with a handle set to NULL.
Signed-off-by: Anatol Pomozov
Signed-off-by: "Theodore Ts'o"
[bwh: Adjust context to apply after commit 0e9a9a1ad619
('ext4: avoid hang when mounting non-journal filesystems with orphan list')
and commit e2bfb088fac0
('ext4: don't orphan or truncate the boot loader inode')]
Signed-off-by: Ben Hutchings
---
fs/ext4/namei.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -1986,7 +1986,7 @@ int ext4_orphan_add(handle_t *handle, st
struct ext4_iloc iloc;
int err = 0, rc;
- if (!ext4_handle_valid(handle) || is_bad_inode(inode))
+ if (!EXT4_SB(sb)->s_journal || is_bad_inode(inode))
return 0;
mutex_lock(&EXT4_SB(sb)->s_orphan_lock);
@@ -2060,8 +2060,7 @@ int ext4_orphan_del(handle_t *handle, st
struct ext4_iloc iloc;
int err = 0;
- /* ext4_handle_valid() assumes a valid handle_t pointer */
- if (handle && !ext4_handle_valid(handle) &&
+ if (!EXT4_SB(inode->i_sb)->s_journal &&
!(EXT4_SB(inode->i_sb)->s_mount_state & EXT4_ORPHAN_FS))
return 0;
@@ -2081,7 +2080,7 @@ int ext4_orphan_del(handle_t *handle, st
* transaction handle with which to update the orphan list on
* disk, but we still need to remove the inode from the linked
* list in memory. */
- if (sbi->s_journal && !handle)
+ if (!handle)
goto out;
err = ext4_reserve_inode_write(handle, inode, &iloc);
--
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.2 01/27] drm/i915: Unlock panel even when LVDS is disabled
3.2.66-rc1 review patch. If anyone has any objections, please let me know.
--
From: Daniel Vetter
commit b0616c5306b342ceca07044dbc4f917d95c4f825 upstream.
Otherwise we'll have backtraces in assert_panel_unlocked because the
BIOS locks the register. In the reporter's case this regression was
introduced in
commit c31407a3672aaebb4acddf90944a114fa5c8af7b
Author: Chris Wilson
Date: Thu Oct 18 21:07:01 2012 +0100
drm/i915: Add no-lvds quirk for Supermicro X7SPA-H
Reported-by: Alexey Orishko
Cc: Alexey Orishko
Cc: Chris Wilson
Cc: Francois Tigeot
Signed-off-by: Daniel Vetter
Tested-by: Alexey Orishko
Signed-off-by: Jani Nikula
[bwh: Backported to 3.2: adjust context; comment was duplicated]
Signed-off-by: Ben Hutchings
---
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -914,6 +914,18 @@ bool intel_lvds_init(struct drm_device *
int pipe;
u8 pin;
+ /*
+* Unlock registers and just leave them unlocked. Do this before
+* checking quirk lists to avoid bogus WARNINGs.
+*/
+ if (HAS_PCH_SPLIT(dev)) {
+ I915_WRITE(PCH_PP_CONTROL,
+ I915_READ(PCH_PP_CONTROL) | PANEL_UNLOCK_REGS);
+ } else {
+ I915_WRITE(PP_CONTROL,
+ I915_READ(PP_CONTROL) | PANEL_UNLOCK_REGS);
+ }
+
/* Skip init on machines we know falsely report LVDS */
if (dmi_check_system(intel_no_lvds))
return false;
@@ -1088,19 +1100,6 @@ out:
pwm = I915_READ(BLC_PWM_PCH_CTL1);
pwm |= PWM_PCH_ENABLE;
I915_WRITE(BLC_PWM_PCH_CTL1, pwm);
- /*
-* Unlock registers and just
-* leave them unlocked
-*/
- I915_WRITE(PCH_PP_CONTROL,
- I915_READ(PCH_PP_CONTROL) | PANEL_UNLOCK_REGS);
- } else {
- /*
-* Unlock registers and just
-* leave them unlocked
-*/
- I915_WRITE(PP_CONTROL,
- I915_READ(PP_CONTROL) | PANEL_UNLOCK_REGS);
}
dev_priv->lid_notifier.notifier_call = intel_lid_notify;
if (acpi_lid_notifier_register(&dev_priv->lid_notifier)) {
--
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.2 22/27] tcp: md5: remove spinlock usage in fast path
3.2.66-rc1 review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
commit 71cea17ed39fdf1c0634f530ddc6a2c2fc601c2b upstream.
TCP md5 code uses per cpu variables but protects access to them with
a shared spinlock, which is a contention point.
[ tcp_md5sig_pool_lock is locked twice per incoming packet ]
Makes things much simpler, by allocating crypto structures once, first
time a socket needs md5 keys, and not deallocating them as they are
really small.
Next step would be to allow crypto allocations being done in a NUMA
aware way.
Signed-off-by: Eric Dumazet
Cc: Herbert Xu
Signed-off-by: David S. Miller
[bwh: Backported to 3.2:
- Adjust context
- Conditions for alloc/free are quite different]
Signed-off-by: Ben Hutchings
---
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1214,11 +1214,13 @@ extern int tcp_v4_md5_do_del(struct sock
#define tcp_twsk_md5_key(twsk) NULL
#endif
-extern struct tcp_md5sig_pool __percpu *tcp_alloc_md5sig_pool(struct sock *);
-extern void tcp_free_md5sig_pool(void);
+extern bool tcp_alloc_md5sig_pool(void);
extern struct tcp_md5sig_pool *tcp_get_md5sig_pool(void);
-extern void tcp_put_md5sig_pool(void);
+static inline void tcp_put_md5sig_pool(void)
+{
+ local_bh_enable();
+}
extern int tcp_md5_hash_header(struct tcp_md5sig_pool *, const struct tcphdr
*);
extern int tcp_md5_hash_skb_data(struct tcp_md5sig_pool *, const struct
sk_buff *,
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2863,9 +2863,8 @@ int tcp_gro_complete(struct sk_buff *skb
EXPORT_SYMBOL(tcp_gro_complete);
#ifdef CONFIG_TCP_MD5SIG
-static unsigned long tcp_md5sig_users;
-static struct tcp_md5sig_pool __percpu *tcp_md5sig_pool;
-static DEFINE_SPINLOCK(tcp_md5sig_pool_lock);
+static struct tcp_md5sig_pool __percpu *tcp_md5sig_pool __read_mostly;
+static DEFINE_MUTEX(tcp_md5sig_mutex);
static void __tcp_free_md5sig_pool(struct tcp_md5sig_pool __percpu *pool)
{
@@ -2880,30 +2879,14 @@ static void __tcp_free_md5sig_pool(struc
free_percpu(pool);
}
-void tcp_free_md5sig_pool(void)
-{
- struct tcp_md5sig_pool __percpu *pool = NULL;
-
- spin_lock_bh(&tcp_md5sig_pool_lock);
- if (--tcp_md5sig_users == 0) {
- pool = tcp_md5sig_pool;
- tcp_md5sig_pool = NULL;
- }
- spin_unlock_bh(&tcp_md5sig_pool_lock);
- if (pool)
- __tcp_free_md5sig_pool(pool);
-}
-EXPORT_SYMBOL(tcp_free_md5sig_pool);
-
-static struct tcp_md5sig_pool __percpu *
-__tcp_alloc_md5sig_pool(struct sock *sk)
+static void __tcp_alloc_md5sig_pool(void)
{
int cpu;
struct tcp_md5sig_pool __percpu *pool;
pool = alloc_percpu(struct tcp_md5sig_pool);
if (!pool)
- return NULL;
+ return;
for_each_possible_cpu(cpu) {
struct crypto_hash *hash;
@@ -2914,53 +2897,27 @@ __tcp_alloc_md5sig_pool(struct sock *sk)
per_cpu_ptr(pool, cpu)->md5_desc.tfm = hash;
}
- return pool;
+ /* before setting tcp_md5sig_pool, we must commit all writes
+* to memory. See ACCESS_ONCE() in tcp_get_md5sig_pool()
+*/
+ smp_wmb();
+ tcp_md5sig_pool = pool;
+ return;
out_free:
__tcp_free_md5sig_pool(pool);
- return NULL;
}
-struct tcp_md5sig_pool __percpu *tcp_alloc_md5sig_pool(struct sock *sk)
+bool tcp_alloc_md5sig_pool(void)
{
- struct tcp_md5sig_pool __percpu *pool;
- int alloc = 0;
+ if (unlikely(!tcp_md5sig_pool)) {
+ mutex_lock(&tcp_md5sig_mutex);
+
+ if (!tcp_md5sig_pool)
+ __tcp_alloc_md5sig_pool();
-retry:
- spin_lock_bh(&tcp_md5sig_pool_lock);
- pool = tcp_md5sig_pool;
- if (tcp_md5sig_users++ == 0) {
- alloc = 1;
- spin_unlock_bh(&tcp_md5sig_pool_lock);
- } else if (!pool) {
- tcp_md5sig_users--;
- spin_unlock_bh(&tcp_md5sig_pool_lock);
- cpu_relax();
- goto retry;
- } else
- spin_unlock_bh(&tcp_md5sig_pool_lock);
-
- if (alloc) {
- /* we cannot hold spinlock here because this may sleep. */
- struct tcp_md5sig_pool __percpu *p;
-
- p = __tcp_alloc_md5sig_pool(sk);
- spin_lock_bh(&tcp_md5sig_pool_lock);
- if (!p) {
- tcp_md5sig_users--;
- spin_unlock_bh(&tcp_md5sig_pool_lock);
- return NULL;
- }
- pool = tcp_md5sig_pool;
- if (pool) {
- /* oops, it has already been assigned. */
- spin_unlock_bh(&tcp_md5sig_pool_lock);
- __tcp_free_md5sig_pool(p);
- } else {
- tcp_md5sig_pool = pool = p;
- spin_unlock_bh(&tcp_md5sig_pool_lock);
- }
[PATCH 3.2 14/27] deal with deadlock in d_walk()
3.2.66-rc1 review patch. If anyone has any objections, please let me know.
--
From: Al Viro
commit ca5358ef75fc69fee5322a38a340f5739d997c10 upstream.
... by not hitting rename_retry for reasons other than rename having
happened. In other words, do _not_ restart when finding that
between unlocking the child and locking the parent the former got
into __dentry_kill(). Skip the killed siblings instead...
Signed-off-by: Al Viro
[bwh: Backported to 3.2:
- As we only have try_to_ascend() and not d_walk(), apply this
change to all callers of try_to_ascend()
- Adjust context to make __dentry_kill() apply to d_kill()]
Signed-off-by: Ben Hutchings
---
fs/dcache.c | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -306,9 +306,9 @@ static struct dentry *d_kill(struct dent
__releases(parent->d_lock)
__releases(dentry->d_inode->i_lock)
{
- list_del(&dentry->d_child);
+ __list_del_entry(&dentry->d_child);
/*
-* Inform try_to_ascend() that we are no longer attached to the
+* Inform ascending readers that we are no longer attached to the
* dentry tree
*/
dentry->d_flags |= DCACHE_DENTRY_KILLED;
@@ -949,34 +949,6 @@ void shrink_dcache_for_umount(struct sup
}
}
-/*
- * This tries to ascend one level of parenthood, but
- * we can race with renaming, so we need to re-check
- * the parenthood after dropping the lock and check
- * that the sequence number still matches.
- */
-static struct dentry *try_to_ascend(struct dentry *old, int locked, unsigned
seq)
-{
- struct dentry *new = old->d_parent;
-
- rcu_read_lock();
- spin_unlock(&old->d_lock);
- spin_lock(&new->d_lock);
-
- /*
-* might go back up the wrong parent if we have had a rename
-* or deletion
-*/
- if (new != old->d_parent ||
-(old->d_flags & DCACHE_DENTRY_KILLED) ||
-(!locked && read_seqretry(&rename_lock, seq))) {
- spin_unlock(&new->d_lock);
- new = NULL;
- }
- rcu_read_unlock();
- return new;
-}
-
/*
* Search for at least 1 mount point in the dentry's subdirs.
@@ -1032,17 +1004,32 @@ resume:
/*
* All done at this level ... ascend and resume the search.
*/
+ rcu_read_lock();
+ascend:
if (this_parent != parent) {
struct dentry *child = this_parent;
- this_parent = try_to_ascend(this_parent, locked, seq);
- if (!this_parent)
+ this_parent = child->d_parent;
+
+ spin_unlock(&child->d_lock);
+ spin_lock(&this_parent->d_lock);
+
+ /* might go back up the wrong parent if we have had a rename */
+ if (!locked && read_seqretry(&rename_lock, seq))
goto rename_retry;
next = child->d_child.next;
+ while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED)) {
+ if (next == &this_parent->d_subdirs)
+ goto ascend;
+ child = list_entry(next, struct dentry, d_child);
+ next = next->next;
+ }
+ rcu_read_unlock();
goto resume;
}
- spin_unlock(&this_parent->d_lock);
if (!locked && read_seqretry(&rename_lock, seq))
goto rename_retry;
+ spin_unlock(&this_parent->d_lock);
+ rcu_read_unlock();
if (locked)
write_sequnlock(&rename_lock);
return 0; /* No mount points found in tree */
@@ -1054,6 +1041,8 @@ positive:
return 1;
rename_retry:
+ spin_unlock(&this_parent->d_lock);
+ rcu_read_unlock();
if (locked)
goto again;
locked = 1;
@@ -1139,23 +1128,40 @@ resume:
/*
* All done at this level ... ascend and resume the search.
*/
+ rcu_read_lock();
+ascend:
if (this_parent != parent) {
struct dentry *child = this_parent;
- this_parent = try_to_ascend(this_parent, locked, seq);
- if (!this_parent)
+ this_parent = child->d_parent;
+
+ spin_unlock(&child->d_lock);
+ spin_lock(&this_parent->d_lock);
+
+ /* might go back up the wrong parent if we have had a rename */
+ if (!locked && read_seqretry(&rename_lock, seq))
goto rename_retry;
next = child->d_child.next;
+ while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED)) {
+ if (next == &this_parent->d_subdirs)
+ goto ascend;
+ child = list_entry(next, struct dentry, d_child);
+ next = next->next;
+ }
+ rcu_read_unlo
[PATCH 3.2 06/27] i2c: davinci: generate STP always when NACK is received
3.2.66-rc1 review patch. If anyone has any objections, please let me know.
--
From: Grygorii Strashko
commit 9ea359f7314132cbcb5a502d2d8ef095be1f45e4 upstream.
According to I2C specification the NACK should be handled as follows:
"When SDA remains HIGH during this ninth clock pulse, this is defined as the Not
Acknowledge signal. The master can then generate either a STOP condition to
abort the transfer, or a repeated START condition to start a new transfer."
[I2C spec Rev. 6, 3.1.6: http://www.nxp.com/documents/user_manual/UM10204.pdf]
Currently the Davinci i2c driver interrupts the transfer on receipt of a
NACK but fails to send a STOP in some situations and so makes the bus
stuck until next I2C IP reset (idle/enable).
For example, the issue will happen during SMBus read transfer which
consists from two i2c messages write command/address and read data:
S Slave Address Wr A Command Code A Sr Slave Address Rd A D1..Dn A P
<--- write ---> <--- read ->
The I2C client device will send NACK if it can't recognize "Command Code"
and it's expected from I2C master to generate STP in this case.
But now, Davinci i2C driver will just exit with -EREMOTEIO and STP will
not be generated.
Hence, fix it by generating Stop condition (STP) always when NACK is received.
This patch fixes Davinci I2C in the same way it was done for OMAP I2C
commit cda2109a26eb ("i2c: omap: query STP always when NACK is received").
Reviewed-by: Uwe Kleine-König
Reported-by: Hein Tibosch
Signed-off-by: Grygorii Strashko
Signed-off-by: Wolfram Sang
Signed-off-by: Ben Hutchings
---
drivers/i2c/busses/i2c-davinci.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -416,11 +416,9 @@ i2c_davinci_xfer_msg(struct i2c_adapter
if (dev->cmd_err & DAVINCI_I2C_STR_NACK) {
if (msg->flags & I2C_M_IGNORE_NAK)
return msg->len;
- if (stop) {
- w = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG);
- w |= DAVINCI_I2C_MDR_STP;
- davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, w);
- }
+ w = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG);
+ w |= DAVINCI_I2C_MDR_STP;
+ davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, w);
return -EREMOTEIO;
}
return -EIO;
--
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.2 10/27] x86/tls: Validate TLS entries to protect espfix
3.2.66-rc1 review patch. If anyone has any objections, please let me know.
--
From: Andy Lutomirski
commit 41bdc78544b8a93a9c6814b8bbbfef966272abbe upstream.
Installing a 16-bit RW data segment into the GDT defeats espfix.
AFAICT this will not affect glibc, Wine, or dosemu at all.
Signed-off-by: Andy Lutomirski
Acked-by: H. Peter Anvin
Cc: Konrad Rzeszutek Wilk
Cc: Linus Torvalds
Cc: secur...@kernel.org
Cc: Willy Tarreau
Signed-off-by: Ingo Molnar
Signed-off-by: Ben Hutchings
---
arch/x86/kernel/tls.c | 23 +++
1 file changed, 23 insertions(+)
--- a/arch/x86/kernel/tls.c
+++ b/arch/x86/kernel/tls.c
@@ -28,6 +28,21 @@ static int get_free_idx(void)
return -ESRCH;
}
+static bool tls_desc_okay(const struct user_desc *info)
+{
+ if (LDT_empty(info))
+ return true;
+
+ /*
+* espfix is required for 16-bit data segments, but espfix
+* only works for LDT segments.
+*/
+ if (!info->seg_32bit)
+ return false;
+
+ return true;
+}
+
static void set_tls_desc(struct task_struct *p, int idx,
const struct user_desc *info, int n)
{
@@ -67,6 +82,9 @@ int do_set_thread_area(struct task_struc
if (copy_from_user(&info, u_info, sizeof(info)))
return -EFAULT;
+ if (!tls_desc_okay(&info))
+ return -EINVAL;
+
if (idx == -1)
idx = info.entry_number;
@@ -197,6 +215,7 @@ int regset_tls_set(struct task_struct *t
{
struct user_desc infobuf[GDT_ENTRY_TLS_ENTRIES];
const struct user_desc *info;
+ int i;
if (pos >= GDT_ENTRY_TLS_ENTRIES * sizeof(struct user_desc) ||
(pos % sizeof(struct user_desc)) != 0 ||
@@ -210,6 +229,10 @@ int regset_tls_set(struct task_struct *t
else
info = infobuf;
+ for (i = 0; i < count / sizeof(struct user_desc); i++)
+ if (!tls_desc_okay(info + i))
+ return -EINVAL;
+
set_tls_desc(target,
GDT_ENTRY_TLS_MIN + (pos / sizeof(struct user_desc)),
info, count / sizeof(struct user_desc));
--
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.2 18/27] crypto: ghash-clmulni-intel - use C implementation for setkey()
3.2.66-rc1 review patch. If anyone has any objections, please let me know.
--
From: Ard Biesheuvel
commit 8ceee72808d1ae3fb191284afc2257a2be964725 upstream.
The GHASH setkey() function uses SSE registers but fails to call
kernel_fpu_begin()/kernel_fpu_end(). Instead of adding these calls, and
then having to deal with the restriction that they cannot be called from
interrupt context, move the setkey() implementation to the C domain.
Note that setkey() does not use any particular SSE features and is not
expected to become a performance bottleneck.
Signed-off-by: Ard Biesheuvel
Acked-by: H. Peter Anvin
Fixes: 0e1227d356e9b (crypto: ghash - Add PCLMULQDQ accelerated implementation)
Signed-off-by: Herbert Xu
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings
---
arch/x86/crypto/ghash-clmulni-intel_asm.S | 29 -
arch/x86/crypto/ghash-clmulni-intel_glue.c | 14 +++---
2 files changed, 11 insertions(+), 32 deletions(-)
--- a/arch/x86/crypto/ghash-clmulni-intel_asm.S
+++ b/arch/x86/crypto/ghash-clmulni-intel_asm.S
@@ -24,10 +24,6 @@
.align 16
.Lbswap_mask:
.octa 0x000102030405060708090a0b0c0d0e0f
-.Lpoly:
- .octa 0xc201
-.Ltwo_one:
- .octa 0x00010001
#define DATA %xmm0
#define SHASH %xmm1
@@ -131,27 +127,3 @@ ENTRY(clmul_ghash_update)
movups DATA, (%rdi)
.Lupdate_just_ret:
ret
-
-/*
- * void clmul_ghash_setkey(be128 *shash, const u8 *key);
- *
- * Calculate hash_key << 1 mod poly
- */
-ENTRY(clmul_ghash_setkey)
- movaps .Lbswap_mask, BSWAP
- movups (%rsi), %xmm0
- PSHUFB_XMM BSWAP %xmm0
- movaps %xmm0, %xmm1
- psllq $1, %xmm0
- psrlq $63, %xmm1
- movaps %xmm1, %xmm2
- pslldq $8, %xmm1
- psrldq $8, %xmm2
- por %xmm1, %xmm0
- # reduction
- pshufd $0b00100100, %xmm2, %xmm1
- pcmpeqd .Ltwo_one, %xmm1
- pand .Lpoly, %xmm1
- pxor %xmm1, %xmm0
- movups %xmm0, (%rdi)
- ret
--- a/arch/x86/crypto/ghash-clmulni-intel_glue.c
+++ b/arch/x86/crypto/ghash-clmulni-intel_glue.c
@@ -29,8 +29,6 @@ void clmul_ghash_mul(char *dst, const be
void clmul_ghash_update(char *dst, const char *src, unsigned int srclen,
const be128 *shash);
-void clmul_ghash_setkey(be128 *shash, const u8 *key);
-
struct ghash_async_ctx {
struct cryptd_ahash *cryptd_tfm;
};
@@ -57,13 +55,23 @@ static int ghash_setkey(struct crypto_sh
const u8 *key, unsigned int keylen)
{
struct ghash_ctx *ctx = crypto_shash_ctx(tfm);
+ be128 *x = (be128 *)key;
+ u64 a, b;
if (keylen != GHASH_BLOCK_SIZE) {
crypto_shash_set_flags(tfm, CRYPTO_TFM_RES_BAD_KEY_LEN);
return -EINVAL;
}
- clmul_ghash_setkey(&ctx->shash, key);
+ /* perform multiplication by 'x' in GF(2^128) */
+ a = be64_to_cpu(x->a);
+ b = be64_to_cpu(x->b);
+
+ ctx->shash.a = (__be64)((b << 1) | (a >> 63));
+ ctx->shash.b = (__be64)((a << 1) | (b >> 63));
+
+ if (a >> 63)
+ ctx->shash.b ^= cpu_to_be64(0xc2);
return 0;
}
--
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.2 23/27] tcp: md5: do not use alloc_percpu()
3.2.66-rc1 review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
commit 349ce993ac706869d553a1816426d3a4bfda02b1 upstream.
percpu tcp_md5sig_pool contains memory blobs that ultimately
go through sg_set_buf().
-> sg_set_page(sg, virt_to_page(buf), buflen, offset_in_page(buf));
This requires that whole area is in a physically contiguous portion
of memory. And that @buf is not backed by vmalloc().
Given that alloc_percpu() can use vmalloc() areas, this does not
fit the requirements.
Replace alloc_percpu() by a static DEFINE_PER_CPU() as tcp_md5sig_pool
is small anyway, there is no gain to dynamically allocate it.
Signed-off-by: Eric Dumazet
Fixes: 765cf9976e93 ("tcp: md5: remove one indirection level in
tcp_md5sig_pool")
Reported-by: Crestez Dan Leonard
Signed-off-by: David S. Miller
[bwh: Backported to 3.2: the deleted code differs slightly due to API changes]
Signed-off-by: Ben Hutchings
---
net/ipv4/tcp.c | 59 --
1 file changed, 20 insertions(+), 39 deletions(-)
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2863,61 +2863,42 @@ int tcp_gro_complete(struct sk_buff *skb
EXPORT_SYMBOL(tcp_gro_complete);
#ifdef CONFIG_TCP_MD5SIG
-static struct tcp_md5sig_pool __percpu *tcp_md5sig_pool __read_mostly;
+static DEFINE_PER_CPU(struct tcp_md5sig_pool, tcp_md5sig_pool);
static DEFINE_MUTEX(tcp_md5sig_mutex);
-
-static void __tcp_free_md5sig_pool(struct tcp_md5sig_pool __percpu *pool)
-{
- int cpu;
-
- for_each_possible_cpu(cpu) {
- struct tcp_md5sig_pool *p = per_cpu_ptr(pool, cpu);
-
- if (p->md5_desc.tfm)
- crypto_free_hash(p->md5_desc.tfm);
- }
- free_percpu(pool);
-}
+static bool tcp_md5sig_pool_populated = false;
static void __tcp_alloc_md5sig_pool(void)
{
int cpu;
- struct tcp_md5sig_pool __percpu *pool;
-
- pool = alloc_percpu(struct tcp_md5sig_pool);
- if (!pool)
- return;
for_each_possible_cpu(cpu) {
- struct crypto_hash *hash;
+ if (!per_cpu(tcp_md5sig_pool, cpu).md5_desc.tfm) {
+ struct crypto_hash *hash;
- hash = crypto_alloc_hash("md5", 0, CRYPTO_ALG_ASYNC);
- if (!hash || IS_ERR(hash))
- goto out_free;
-
- per_cpu_ptr(pool, cpu)->md5_desc.tfm = hash;
+ hash = crypto_alloc_hash("md5", 0, CRYPTO_ALG_ASYNC);
+ if (IS_ERR_OR_NULL(hash))
+ return;
+ per_cpu(tcp_md5sig_pool, cpu).md5_desc.tfm = hash;
+ }
}
- /* before setting tcp_md5sig_pool, we must commit all writes
-* to memory. See ACCESS_ONCE() in tcp_get_md5sig_pool()
+ /* before setting tcp_md5sig_pool_populated, we must commit all writes
+* to memory. See smp_rmb() in tcp_get_md5sig_pool()
*/
smp_wmb();
- tcp_md5sig_pool = pool;
- return;
-out_free:
- __tcp_free_md5sig_pool(pool);
+ tcp_md5sig_pool_populated = true;
}
bool tcp_alloc_md5sig_pool(void)
{
- if (unlikely(!tcp_md5sig_pool)) {
+ if (unlikely(!tcp_md5sig_pool_populated)) {
mutex_lock(&tcp_md5sig_mutex);
- if (!tcp_md5sig_pool)
+ if (!tcp_md5sig_pool_populated)
__tcp_alloc_md5sig_pool();
mutex_unlock(&tcp_md5sig_mutex);
}
- return tcp_md5sig_pool != NULL;
+ return tcp_md5sig_pool_populated;
}
EXPORT_SYMBOL(tcp_alloc_md5sig_pool);
@@ -2931,13 +2912,13 @@ EXPORT_SYMBOL(tcp_alloc_md5sig_pool);
*/
struct tcp_md5sig_pool *tcp_get_md5sig_pool(void)
{
- struct tcp_md5sig_pool __percpu *p;
-
local_bh_disable();
- p = ACCESS_ONCE(tcp_md5sig_pool);
- if (p)
- return __this_cpu_ptr(p);
+ if (tcp_md5sig_pool_populated) {
+ /* coupled with smp_wmb() in __tcp_alloc_md5sig_pool() */
+ smp_rmb();
+ return this_cpu_ptr(&tcp_md5sig_pool);
+ }
local_bh_enable();
return NULL;
}
--
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.2 13/27] move d_rcu from overlapping d_child to overlapping d_alias
3.2.66-rc1 review patch. If anyone has any objections, please let me know.
--
From: Al Viro
commit 946e51f2bf37f1656916eb75bd0742ba33983c28 upstream.
Signed-off-by: Al Viro
[bwh: Backported to 3.2:
- Apply name changes in all the different places we use d_alias and d_child
- Move the WARN_ON() in __d_free() to d_free() as we don't have dentry_free()]
Signed-off-by: Ben Hutchings
---
--- a/arch/powerpc/platforms/cell/spufs/inode.c
+++ b/arch/powerpc/platforms/cell/spufs/inode.c
@@ -165,7 +165,7 @@ static void spufs_prune_dir(struct dentr
struct dentry *dentry, *tmp;
mutex_lock(&dir->d_inode->i_mutex);
- list_for_each_entry_safe(dentry, tmp, &dir->d_subdirs, d_u.d_child) {
+ list_for_each_entry_safe(dentry, tmp, &dir->d_subdirs, d_child) {
spin_lock(&dentry->d_lock);
if (!(d_unhashed(dentry)) && dentry->d_inode) {
dget_dlock(dentry);
@@ -223,7 +223,7 @@ out:
* - free child's inode if possible
* - free child
*/
- list_for_each_entry_safe(dentry, tmp, &dir->d_subdirs, d_u.d_child) {
+ list_for_each_entry_safe(dentry, tmp, &dir->d_subdirs, d_child) {
dput(dentry);
}
--- a/drivers/usb/core/inode.c
+++ b/drivers/usb/core/inode.c
@@ -212,7 +212,7 @@ static void update_bus(struct dentry *bu
mutex_lock(&bus->d_inode->i_mutex);
- list_for_each_entry(dev, &bus->d_subdirs, d_u.d_child)
+ list_for_each_entry(dev, &bus->d_subdirs, d_child)
if (dev->d_inode)
update_dev(dev);
@@ -229,7 +229,7 @@ static void update_sb(struct super_block
mutex_lock_nested(&root->d_inode->i_mutex, I_MUTEX_PARENT);
- list_for_each_entry(bus, &root->d_subdirs, d_u.d_child) {
+ list_for_each_entry(bus, &root->d_subdirs, d_child) {
if (bus->d_inode) {
switch (S_IFMT & bus->d_inode->i_mode) {
case S_IFDIR:
@@ -345,7 +345,7 @@ static int usbfs_empty (struct dentry *d
spin_lock(&dentry->d_lock);
list_for_each(list, &dentry->d_subdirs) {
- struct dentry *de = list_entry(list, struct dentry,
d_u.d_child);
+ struct dentry *de = list_entry(list, struct dentry, d_child);
spin_lock_nested(&de->d_lock, DENTRY_D_LOCK_NESTED);
if (usbfs_positive(de)) {
--- a/fs/9p/vfs_inode_dotl.c
+++ b/fs/9p/vfs_inode_dotl.c
@@ -81,7 +81,7 @@ static struct dentry *v9fs_dentry_from_d
spin_lock(&inode->i_lock);
/* Directory should have only one entry. */
BUG_ON(S_ISDIR(inode->i_mode) && !list_is_singular(&inode->i_dentry));
- dentry = list_entry(inode->i_dentry.next, struct dentry, d_alias);
+ dentry = list_entry(inode->i_dentry.next, struct dentry, d_u.d_alias);
spin_unlock(&inode->i_lock);
return dentry;
}
--- a/fs/affs/amigaffs.c
+++ b/fs/affs/amigaffs.c
@@ -132,7 +132,7 @@ affs_fix_dcache(struct dentry *dentry, u
head = &inode->i_dentry;
next = head->next;
while (next != head) {
- dentry = list_entry(next, struct dentry, d_alias);
+ dentry = list_entry(next, struct dentry, d_u.d_alias);
if (entry_ino == (u32)(long)dentry->d_fsdata) {
dentry->d_fsdata = data;
break;
--- a/fs/autofs4/expire.c
+++ b/fs/autofs4/expire.c
@@ -100,7 +100,7 @@ static struct dentry *get_next_positive_
p = prev;
spin_lock(&p->d_lock);
again:
- next = p->d_u.d_child.next;
+ next = p->d_child.next;
start:
if (next == &root->d_subdirs) {
spin_unlock(&p->d_lock);
@@ -109,7 +109,7 @@ start:
return NULL;
}
- q = list_entry(next, struct dentry, d_u.d_child);
+ q = list_entry(next, struct dentry, d_child);
spin_lock_nested(&q->d_lock, DENTRY_D_LOCK_NESTED);
/* Negative dentry - try next */
@@ -165,13 +165,13 @@ again:
goto relock;
}
spin_unlock(&p->d_lock);
- next = p->d_u.d_child.next;
+ next = p->d_child.next;
p = parent;
if (next != &parent->d_subdirs)
break;
}
}
- ret = list_entry(next, struct dentry, d_u.d_child);
+ ret = list_entry(next, struct dentry, d_child);
spin_lock_nested(&ret->d_lock, DENTRY_D_LOCK_NESTED);
/* Negative dentry - try next */
@@ -455,7 +455,7 @@ found:
spin_lock(&sbi->lookup_lock);
spin_lock(&expired->d_parent->d_lock);
spin_lock_nested(&expired->d_lock, DENTRY_D_LOCK_NESTED);
- list_move(&expired->d_parent->d_subdirs, &expired->d_u.d_child);
+ list_move(&expired->d_parent->d_subdirs, &expired->d_child);
[PATCH 3.2 09/27] KVM: x86: Don't report guest userspace emulation error to userspace
3.2.66-rc1 review patch. If anyone has any objections, please let me know.
--
From: Nadav Amit
commit a2b9e6c1a35afcc0973acb72e591c714e78885ff upstream.
Commit fc3a9157d314 ("KVM: X86: Don't report L2 emulation failures to
user-space") disabled the reporting of L2 (nested guest) emulation failures to
userspace due to race-condition between a vmexit and the instruction emulator.
The same rational applies also to userspace applications that are permitted by
the guest OS to access MMIO area or perform PIO.
This patch extends the current behavior - of injecting a #UD instead of
reporting it to userspace - also for guest userspace code.
Signed-off-by: Nadav Amit
Signed-off-by: Paolo Bonzini
Signed-off-by: Ben Hutchings
---
arch/x86/kvm/x86.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4846,7 +4846,7 @@ static int handle_emulation_failure(stru
++vcpu->stat.insn_emulation_fail;
trace_kvm_emulate_insn_failed(vcpu);
- if (!is_guest_mode(vcpu)) {
+ if (!is_guest_mode(vcpu) && kvm_x86_ops->get_cpl(vcpu) == 0) {
vcpu->run->exit_reason = KVM_EXIT_INTERNAL_ERROR;
vcpu->run->internal.suberror = KVM_INTERNAL_ERROR_EMULATION;
vcpu->run->internal.ndata = 0;
--
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.2 19/27] drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packets
3.2.66-rc1 review patch. If anyone has any objections, please let me know.
--
From: Ben Hutchings
commit 5188cd44c55db3e92cd9e77a40b5baa7ed4340f7 upstream.
UFO is now disabled on all drivers that work with virtio net headers,
but userland may try to send UFO/IPv6 packets anyway. Instead of
sending with ID=0, we should select identifiers on their behalf (as we
used to).
Signed-off-by: Ben Hutchings
Fixes: 916e4cf46d02 ("ipv6: reuse ip6_frag_id from ip6_ufo_append_data")
Signed-off-by: David S. Miller
[bwh: For 3.2, net/ipv6/output_core.c is a completely new file]
---
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -15,6 +15,7 @@
#include
#include
+#include
#include
#include
#include
@@ -577,6 +578,8 @@ static int macvtap_skb_from_vnet_hdr(str
break;
case VIRTIO_NET_HDR_GSO_UDP:
gso_type = SKB_GSO_UDP;
+ if (skb->protocol == htons(ETH_P_IPV6))
+ ipv6_proxy_select_ident(skb);
break;
default:
return -EINVAL;
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -64,6 +64,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -695,6 +696,8 @@ static ssize_t tun_get_user(struct tun_s
break;
}
+ skb_reset_network_header(skb);
+
if (gso.gso_type != VIRTIO_NET_HDR_GSO_NONE) {
pr_debug("GSO!\n");
switch (gso.gso_type & ~VIRTIO_NET_HDR_GSO_ECN) {
@@ -706,6 +709,8 @@ static ssize_t tun_get_user(struct tun_s
break;
case VIRTIO_NET_HDR_GSO_UDP:
skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
+ if (skb->protocol == htons(ETH_P_IPV6))
+ ipv6_proxy_select_ident(skb);
break;
default:
tun->dev->stats.rx_frame_errors++;
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -481,6 +481,7 @@ static inline int ipv6_addr_diff(const s
}
extern void ipv6_select_ident(struct frag_hdr *fhdr, struct rt6_info *rt);
+void ipv6_proxy_select_ident(struct sk_buff *skb);
/*
* Prototypes exported by ipv6
--- /dev/null
+++ b/net/ipv6/output_core.c
@@ -0,0 +1,38 @@
+#include
+#include
+#include
+#include
+
+/* This function exists only for tap drivers that must support broken
+ * clients requesting UFO without specifying an IPv6 fragment ID.
+ *
+ * This is similar to ipv6_select_ident() but we use an independent hash
+ * seed to limit information leakage.
+ */
+void ipv6_proxy_select_ident(struct sk_buff *skb)
+{
+ static u32 ip6_proxy_idents_hashrnd __read_mostly;
+ static bool hashrnd_initialized = false;
+ struct in6_addr buf[2];
+ struct in6_addr *addrs;
+ u32 hash, id;
+
+ addrs = skb_header_pointer(skb,
+ skb_network_offset(skb) +
+ offsetof(struct ipv6hdr, saddr),
+ sizeof(buf), buf);
+ if (!addrs)
+ return;
+
+ if (unlikely(!hashrnd_initialized)) {
+ hashrnd_initialized = true;
+ get_random_bytes(&ip6_proxy_idents_hashrnd,
+sizeof(ip6_proxy_idents_hashrnd));
+ }
+ hash = __ipv6_addr_jhash(&addrs[1], ip6_proxy_idents_hashrnd);
+ hash = __ipv6_addr_jhash(&addrs[0], hash);
+
+ id = ip_idents_reserve(hash, 1);
+ skb_shinfo(skb)->ip6_frag_id = htonl(id);
+}
+EXPORT_SYMBOL_GPL(ipv6_proxy_select_ident);
--- a/net/ipv6/Makefile
+++ b/net/ipv6/Makefile
@@ -37,6 +37,6 @@ obj-$(CONFIG_NETFILTER) += netfilter/
obj-$(CONFIG_IPV6_SIT) += sit.o
obj-$(CONFIG_IPV6_TUNNEL) += ip6_tunnel.o
-obj-y += addrconf_core.o exthdrs_core.o
+obj-y += addrconf_core.o exthdrs_core.o output_core.o
obj-$(subst m,y,$(CONFIG_IPV6)) += inet6_hashtables.o
--
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.2 07/27] udf: Avoid infinite loop when processing indirect ICBs
3.2.66-rc1 review patch. If anyone has any objections, please let me know.
--
From: Jan Kara
commit c03aa9f6e1f938618e6db2e23afef0574efeeb65 upstream.
We did not implement any bound on number of indirect ICBs we follow when
loading inode. Thus corrupted medium could cause kernel to go into an
infinite loop, possibly causing a stack overflow.
Fix the possible stack overflow by removing recursion from
__udf_read_inode() and limit number of indirect ICBs we follow to avoid
infinite loops.
Signed-off-by: Jan Kara
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings
---
fs/udf/inode.c | 35 +--
1 file changed, 21 insertions(+), 14 deletions(-)
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -1176,13 +1176,22 @@ update_time:
return 0;
}
+/*
+ * Maximum length of linked list formed by ICB hierarchy. The chosen number is
+ * arbitrary - just that we hopefully don't limit any real use of rewritten
+ * inode on write-once media but avoid looping for too long on corrupted media.
+ */
+#define UDF_MAX_ICB_NESTING 1024
+
static void __udf_read_inode(struct inode *inode)
{
struct buffer_head *bh = NULL;
struct fileEntry *fe;
uint16_t ident;
struct udf_inode_info *iinfo = UDF_I(inode);
+ unsigned int indirections = 0;
+reread:
/*
* Set defaults, but the inode is still incomplete!
* Note: get_new_inode() sets the following on a new inode:
@@ -1219,28 +1228,26 @@ static void __udf_read_inode(struct inod
ibh = udf_read_ptagged(inode->i_sb, &iinfo->i_location, 1,
&ident);
if (ident == TAG_IDENT_IE && ibh) {
- struct buffer_head *nbh = NULL;
struct kernel_lb_addr loc;
struct indirectEntry *ie;
ie = (struct indirectEntry *)ibh->b_data;
loc = lelb_to_cpu(ie->indirectICB.extLocation);
- if (ie->indirectICB.extLength &&
- (nbh = udf_read_ptagged(inode->i_sb, &loc, 0,
- &ident))) {
- if (ident == TAG_IDENT_FE ||
- ident == TAG_IDENT_EFE) {
- memcpy(&iinfo->i_location,
- &loc,
- sizeof(struct kernel_lb_addr));
- brelse(bh);
- brelse(ibh);
- brelse(nbh);
- __udf_read_inode(inode);
+ if (ie->indirectICB.extLength) {
+ brelse(bh);
+ brelse(ibh);
+ memcpy(&iinfo->i_location, &loc,
+ sizeof(struct kernel_lb_addr));
+ if (++indirections > UDF_MAX_ICB_NESTING) {
+ udf_err(inode->i_sb,
+ "too many ICBs in ICB hierarchy"
+ " (max %d supported)\n",
+ UDF_MAX_ICB_NESTING);
+ make_bad_inode(inode);
return;
}
- brelse(nbh);
+ goto reread;
}
}
brelse(ibh);
--
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 3.2 00/27] 3.2.66-rc1 review
This is the combined patch for 3.2.66-rc1 relative to 3.2.65.
Ben.
--
Ben Hutchings
Anthony's Law of Force: Don't force it, get a larger hammer.
diff --git a/Makefile b/Makefile
index 1433109..cda7e1d 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 3
PATCHLEVEL = 2
-SUBLEVEL = 65
-EXTRAVERSION =
+SUBLEVEL = 66
+EXTRAVERSION = -rc1
NAME = Saber-toothed Squirrel
# *DOCUMENTATION*
diff --git a/arch/powerpc/platforms/cell/spufs/inode.c b/arch/powerpc/platforms/cell/spufs/inode.c
index 70ec4e9..941d5cb 100644
--- a/arch/powerpc/platforms/cell/spufs/inode.c
+++ b/arch/powerpc/platforms/cell/spufs/inode.c
@@ -165,7 +165,7 @@ static void spufs_prune_dir(struct dentry *dir)
struct dentry *dentry, *tmp;
mutex_lock(&dir->d_inode->i_mutex);
- list_for_each_entry_safe(dentry, tmp, &dir->d_subdirs, d_u.d_child) {
+ list_for_each_entry_safe(dentry, tmp, &dir->d_subdirs, d_child) {
spin_lock(&dentry->d_lock);
if (!(d_unhashed(dentry)) && dentry->d_inode) {
dget_dlock(dentry);
@@ -223,7 +223,7 @@ out:
* - free child's inode if possible
* - free child
*/
- list_for_each_entry_safe(dentry, tmp, &dir->d_subdirs, d_u.d_child) {
+ list_for_each_entry_safe(dentry, tmp, &dir->d_subdirs, d_child) {
dput(dentry);
}
diff --git a/arch/s390/kernel/time.c b/arch/s390/kernel/time.c
index b2f44de..fd65e5e2 100644
--- a/arch/s390/kernel/time.c
+++ b/arch/s390/kernel/time.c
@@ -110,20 +110,10 @@ static void fixup_clock_comparator(unsigned long long delta)
set_clock_comparator(S390_lowcore.clock_comparator);
}
-static int s390_next_ktime(ktime_t expires,
+static int s390_next_event(unsigned long delta,
struct clock_event_device *evt)
{
- struct timespec ts;
- u64 nsecs;
-
- ts.tv_sec = ts.tv_nsec = 0;
- monotonic_to_bootbased(&ts);
- nsecs = ktime_to_ns(ktime_add(timespec_to_ktime(ts), expires));
- do_div(nsecs, 125);
- S390_lowcore.clock_comparator = sched_clock_base_cc + (nsecs << 9);
- /* Program the maximum value if we have an overflow (== year 2042) */
- if (unlikely(S390_lowcore.clock_comparator < sched_clock_base_cc))
- S390_lowcore.clock_comparator = -1ULL;
+ S390_lowcore.clock_comparator = get_clock() + delta;
set_clock_comparator(S390_lowcore.clock_comparator);
return 0;
}
@@ -148,15 +138,14 @@ void init_cpu_timer(void)
cpu = smp_processor_id();
cd = &per_cpu(comparators, cpu);
cd->name = "comparator";
- cd->features = CLOCK_EVT_FEAT_ONESHOT |
- CLOCK_EVT_FEAT_KTIME;
+ cd->features = CLOCK_EVT_FEAT_ONESHOT;
cd->mult = 16777;
cd->shift = 12;
cd->min_delta_ns = 1;
cd->max_delta_ns = LONG_MAX;
cd->rating = 400;
cd->cpumask = cpumask_of(cpu);
- cd->set_next_ktime = s390_next_ktime;
+ cd->set_next_event = s390_next_event;
cd->set_mode = s390_set_mode;
clockevents_register_device(cd);
diff --git a/arch/x86/crypto/ghash-clmulni-intel_asm.S b/arch/x86/crypto/ghash-clmulni-intel_asm.S
index 1eb7f90..eb4d2a2 100644
--- a/arch/x86/crypto/ghash-clmulni-intel_asm.S
+++ b/arch/x86/crypto/ghash-clmulni-intel_asm.S
@@ -24,10 +24,6 @@
.align 16
.Lbswap_mask:
.octa 0x000102030405060708090a0b0c0d0e0f
-.Lpoly:
- .octa 0xc201
-.Ltwo_one:
- .octa 0x00010001
#define DATA %xmm0
#define SHASH %xmm1
@@ -131,27 +127,3 @@ ENTRY(clmul_ghash_update)
movups DATA, (%rdi)
.Lupdate_just_ret:
ret
-
-/*
- * void clmul_ghash_setkey(be128 *shash, const u8 *key);
- *
- * Calculate hash_key << 1 mod poly
- */
-ENTRY(clmul_ghash_setkey)
- movaps .Lbswap_mask, BSWAP
- movups (%rsi), %xmm0
- PSHUFB_XMM BSWAP %xmm0
- movaps %xmm0, %xmm1
- psllq $1, %xmm0
- psrlq $63, %xmm1
- movaps %xmm1, %xmm2
- pslldq $8, %xmm1
- psrldq $8, %xmm2
- por %xmm1, %xmm0
- # reduction
- pshufd $0b00100100, %xmm2, %xmm1
- pcmpeqd .Ltwo_one, %xmm1
- pand .Lpoly, %xmm1
- pxor %xmm1, %xmm0
- movups %xmm0, (%rdi)
- ret
diff --git a/arch/x86/crypto/ghash-clmulni-intel_glue.c b/arch/x86/crypto/ghash-clmulni-intel_glue.c
index 976aa64..294a264 100644
--- a/arch/x86/crypto/ghash-clmulni-intel_glue.c
+++ b/arch/x86/crypto/ghash-clmulni-intel_glue.c
@@ -29,8 +29,6 @@ void clmul_ghash_mul(char *dst, const be128 *shash);
void clmul_ghash_update(char *dst, const char *src, unsigned int srclen,
const be128 *shash);
-void clmul_ghash_setkey(be128 *shash, const u8 *key);
-
struct ghash_async_ctx {
struct cryptd_ahash *cryptd_tfm;
};
@@ -57,13 +55,23 @@ static int ghash_setkey(struct crypto_shash *tfm,
const u8 *key, unsigned int keylen)
{
struct ghash_ctx *ctx = crypto_shash_ctx(tfm);
+ be128 *x = (be128 *)key;
+ u64 a, b;
if (keylen != GHASH_BLOCK_SIZE) {
crypto_shash_set_flags(tfm, CRYPTO_TFM_RES_BAD_KEY_LEN);
return -EINVAL;
}
- clmul_ghash_setkey(&ctx->shash, key);
+ /* perform multiplication by 'x' in GF(2^128) */
+ a = be64_to_cpu(x->a);
+ b = be64_to_cpu(x->b);
+
+ ctx->shash.a = (__be64)((b << 1) | (a >> 63));
+ ctx->shash.b = (__be64)((a << 1) | (b >> 63));
+
+ if (a >> 63)
+ ctx->shash.b ^= cpu_
[PATCH 3.2 03/27] sata_fsl: fix error handling of irq_of_parse_and_map
3.2.66-rc1 review patch. If anyone has any objections, please let me know.
--
From: Dmitry Torokhov
commit aad0b624129709c94c2e19e583b6053520353fa8 upstream.
irq_of_parse_and_map() returns 0 on error (the result is unsigned int),
so testing for negative result never works.
Signed-off-by: Dmitry Torokhov
Signed-off-by: Tejun Heo
Signed-off-by: Ben Hutchings
---
drivers/ata/sata_fsl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -1338,7 +1338,7 @@ static int sata_fsl_probe(struct platfor
host_priv->csr_base = csr_base;
irq = irq_of_parse_and_map(ofdev->dev.of_node, 0);
- if (irq < 0) {
+ if (!irq) {
dev_err(&ofdev->dev, "invalid irq from platform\n");
goto error_exit_with_cleanup;
}
--
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.2 00/27] 3.2.66-rc1 review
This is the start of the stable review cycle for the 3.2.66 release. There are 27 patches in this series, which will be posted as responses to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Dec 31 12:00:00 UTC 2014. Anything received after that time might be too late. A combined patch relative to 3.2.65 will be posted as an additional response to this. A shortlog and diffstat can be found below. Ben. - Al Viro (2): deal with deadlock in d_walk() [ca5358ef75fc69fee5322a38a340f5739d997c10] move d_rcu from overlapping d_child to overlapping d_alias [946e51f2bf37f1656916eb75bd0742ba33983c28] Anatol Pomozov (1): ext4: make orphan functions be no-op in no-journal mode [c9b92530a723ac5ef8e352885a1862b18f31b2f5] Andy Lutomirski (2): x86, kvm: Clear paravirt_enabled on KVM guests for espfix32's benefit [29fa6825463c97e5157284db80107d1bfac5d77b] x86/tls: Validate TLS entries to protect espfix [41bdc78544b8a93a9c6814b8bbbfef966272abbe] Ard Biesheuvel (1): crypto: ghash-clmulni-intel - use C implementation for setkey() [8ceee72808d1ae3fb191284afc2257a2be964725] Ben Hutchings (2): drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packets [5188cd44c55db3e92cd9e77a40b5baa7ed4340f7] drivers/net: macvtap and tun depend on INET [de11b0e8c569b96c2cf6a811e3805b7aeef498a3] Dan Carpenter (1): [media] ttusb-dec: buffer overflow in ioctl [f2e323ec96077642d397bb1c355def536d489d16] Daniel Borkmann (3): net: sctp: fix NULL pointer dereference in af->from_addr_param on malformed packet [e40607cbe270a9e8360907cb1e62ddf0736e4864] net: sctp: fix memory leak in auth key management [4184b2a79a7612a9272ce20d639934584a1f3786] net: sctp: use MAX_HEADER for headroom reserve in output path [9772b54c55266ce80c639a80aa68eeb908f8ecf5] Daniel Vetter (1): drm/i915: Unlock panel even when LVDS is disabled [b0616c5306b342ceca07044dbc4f917d95c4f825] David Herrmann (1): drm: fix DRM_IOCTL_MODE_GETFB handle-leak [101b96f32956ee99bf1468afaf572b88cda9f88b] Devin Ryles (1): AHCI: Add DeviceIDs for Sunrise Point-LP SATA controller [249cd0a187ed4ef1d0af7f74362cc2791ec5581b] Dmitry Torokhov (1): sata_fsl: fix error handling of irq_of_parse_and_map [aad0b624129709c94c2e19e583b6053520353fa8] Eric Dumazet (2): tcp: md5: do not use alloc_percpu() [349ce993ac706869d553a1816426d3a4bfda02b1] tcp: md5: remove spinlock usage in fast path [71cea17ed39fdf1c0634f530ddc6a2c2fc601c2b] Grygorii Strashko (1): i2c: davinci: generate STP always when NACK is received [9ea359f7314132cbcb5a502d2d8ef095be1f45e4] Hugh Dickins (1): mm: fix swapoff hang after page migration and fork [2022b4d18a491a578218ce7a4eca8666db895a73] Jan Kara (1): udf: Avoid infinite loop when processing indirect ICBs [c03aa9f6e1f938618e6db2e23afef0574efeeb65] Jiri Pirko (1): ipv4: fix nexthop attlen check in fib_nh_match [f76936d07c4eeb36d8dbb64ebd30ab46ff85d9f7] Martin Schwidefsky (1): s390,time: revert direct ktime path for s390 clockevent device [8adbf78ec4839c1dc4ff20c9a1f332a7bc99e6e6] Nadav Amit (1): KVM: x86: Don't report guest userspace emulation error to userspace [a2b9e6c1a35afcc0973acb72e591c714e78885ff] Paolo Bonzini (1): x86: kvm: use alternatives for VMCALL vs. VMMCALL if kernel text is read-only [c1118b3602c2329671ad5ec8bdf8e374323d6343] Tejun Heo (1): ahci: disable MSI on SAMSUNG 0xa800 SSD [2b21ef0aae65f22f5ba86b13c4588f6f0c2dbefb] Vasily Averin (1): ipv4: dst_entry leak in ip_send_unicast_reply() [4062090e3e5caaf55bed4523a69f26c3265cc1d2] Makefile | 4 +- arch/powerpc/platforms/cell/spufs/inode.c | 4 +- arch/s390/kernel/time.c| 19 +-- arch/x86/crypto/ghash-clmulni-intel_asm.S | 28 - arch/x86/crypto/ghash-clmulni-intel_glue.c | 14 ++- arch/x86/include/asm/cpufeature.h | 1 + arch/x86/include/asm/kvm_para.h| 10 +- arch/x86/kernel/cpu/amd.c | 7 ++ arch/x86/kernel/kvm.c | 9 +- arch/x86/kernel/kvmclock.c | 1 - arch/x86/kernel/tls.c | 23 arch/x86/kvm/x86.c | 2 +- drivers/ata/ahci.c | 4 + drivers/ata/sata_fsl.c | 2 +- drivers/gpu/drm/drm_crtc.c | 12 +- drivers/gpu/drm/i915/intel_lvds.c | 25 ++-- drivers/i2c/busses/i2c-davinci.c | 8 +- drivers/media/dvb/ttusb-dec/ttusbdecfe.c | 3 + drivers/net/Kconfig| 2 + drivers/net/macvtap.c |
[PATCH 3.2 11/27] [media] ttusb-dec: buffer overflow in ioctl
3.2.66-rc1 review patch. If anyone has any objections, please let me know. -- From: Dan Carpenter commit f2e323ec96077642d397bb1c355def536d489d16 upstream. We need to add a limit check here so we don't overflow the buffer. Signed-off-by: Dan Carpenter Signed-off-by: Mauro Carvalho Chehab [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings --- drivers/media/dvb/ttusb-dec/ttusbdecfe.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/media/dvb/ttusb-dec/ttusbdecfe.c +++ b/drivers/media/dvb/ttusb-dec/ttusbdecfe.c @@ -154,6 +154,9 @@ static int ttusbdecfe_dvbs_diseqc_send_m 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }; + if (cmd->msg_len > sizeof(b) - 4) + return -EINVAL; + memcpy(&b[4], cmd->msg, cmd->msg_len); state->config->send_command(fe, 0x72, -- 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.2 21/27] ipv4: fix nexthop attlen check in fib_nh_match
3.2.66-rc1 review patch. If anyone has any objections, please let me know.
--
From: Jiri Pirko
commit f76936d07c4eeb36d8dbb64ebd30ab46ff85d9f7 upstream.
fib_nh_match does not match nexthops correctly. Example:
ip route add 172.16.10/24 nexthop via 192.168.122.12 dev eth0 \
nexthop via 192.168.122.13 dev eth0
ip route del 172.16.10/24 nexthop via 192.168.122.14 dev eth0 \
nexthop via 192.168.122.15 dev eth0
Del command is successful and route is removed. After this patch
applied, the route is correctly matched and result is:
RTNETLINK answers: No such process
Please consider this for stable trees as well.
Fixes: 4e902c57417c4 ("[IPv4]: FIB configuration using struct fib_config")
Signed-off-by: Jiri Pirko
Acked-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
net/ipv4/fib_semantics.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -467,7 +467,7 @@ int fib_nh_match(struct fib_config *cfg,
return 1;
attrlen = rtnh_attrlen(rtnh);
- if (attrlen < 0) {
+ if (attrlen > 0) {
struct nlattr *nla, *attrs = rtnh_attrs(rtnh);
nla = nla_find(attrs, attrlen, RTA_GATEWAY);
--
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.2 26/27] net: sctp: use MAX_HEADER for headroom reserve in output path
3.2.66-rc1 review patch. If anyone has any objections, please let me know.
--
From: Daniel Borkmann
commit 9772b54c55266ce80c639a80aa68eeb908f8ecf5 upstream.
To accomodate for enough headroom for tunnels, use MAX_HEADER instead
of LL_MAX_HEADER. Robert reported that he has hit after roughly 40hrs
of trinity an skb_under_panic() via SCTP output path (see reference).
I couldn't reproduce it from here, but not using MAX_HEADER as elsewhere
in other protocols might be one possible cause for this.
In any case, it looks like accounting on chunks themself seems to look
good as the skb already passed the SCTP output path and did not hit
any skb_over_panic(). Given tunneling was enabled in his .config, the
headroom would have been expanded by MAX_HEADER in this case.
Reported-by: Robert Święcki
Reference: https://lkml.org/lkml/2014/12/1/507
Fixes: 594ccc14dfe4d ("[SCTP] Replace incorrect use of dev_alloc_skb with
alloc_skb in sctp_packet_transmit().")
Signed-off-by: Daniel Borkmann
Acked-by: Vlad Yasevich
Acked-by: Neil Horman
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
net/sctp/output.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/net/sctp/output.c
+++ b/net/sctp/output.c
@@ -384,12 +384,12 @@ int sctp_packet_transmit(struct sctp_pac
sk = chunk->skb->sk;
/* Allocate the new skb. */
- nskb = alloc_skb(packet->size + LL_MAX_HEADER, GFP_ATOMIC);
+ nskb = alloc_skb(packet->size + MAX_HEADER, GFP_ATOMIC);
if (!nskb)
goto nomem;
/* Make sure the outbound skb has enough header room reserved. */
- skb_reserve(nskb, packet->overhead + LL_MAX_HEADER);
+ skb_reserve(nskb, packet->overhead + MAX_HEADER);
/* Set the owning socket so that we know where to get the
* destination IP address.
--
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.2 05/27] ahci: disable MSI on SAMSUNG 0xa800 SSD
3.2.66-rc1 review patch. If anyone has any objections, please let me know.
--
From: Tejun Heo
commit 2b21ef0aae65f22f5ba86b13c4588f6f0c2dbefb upstream.
Just like 0x1600 which got blacklisted by 66a7cbc303f4 ("ahci: disable
MSI instead of NCQ on Samsung pci-e SSDs on macbooks"), 0xa800 chokes
on NCQ commands if MSI is enabled. Disable MSI.
Signed-off-by: Tejun Heo
Reported-by: Dominik Mierzejewski
Link: https://bugzilla.kernel.org/show_bug.cgi?id=89171
Signed-off-by: Ben Hutchings
---
drivers/ata/ahci.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -502,6 +502,7 @@ static const struct pci_device_id ahci_p
* enabled. https://bugzilla.kernel.org/show_bug.cgi?id=60731
*/
{ PCI_VDEVICE(SAMSUNG, 0x1600), board_ahci_nomsi },
+ { PCI_VDEVICE(SAMSUNG, 0xa800), board_ahci_nomsi },
/* Enmotus */
{ PCI_DEVICE(0x1c44, 0x8000), board_ahci },
--
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.2 24/27] ipv4: dst_entry leak in ip_send_unicast_reply()
3.2.66-rc1 review patch. If anyone has any objections, please let me know.
--
From: Vasily Averin
commit 4062090e3e5caaf55bed4523a69f26c3265cc1d2 upstream.
ip_setup_cork() called inside ip_append_data() steals dst entry from rt to cork
and in case errors in __ip_append_data() nobody frees stolen dst entry
Fixes: 2e77d89b2fa8 ("net: avoid a pair of dst_hold()/dst_release() in
ip_append_data()")
Signed-off-by: Vasily Averin
Acked-by: Eric Dumazet
Signed-off-by: David S. Miller
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings
---
net/ipv4/ip_output.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -1472,6 +1472,7 @@ void ip_send_reply(struct sock *sk, stru
struct ipcm_cookie ipc;
struct flowi4 fl4;
struct rtable *rt = skb_rtable(skb);
+ int err;
if (ip_options_echo(&replyopts.opt.opt, skb))
return;
@@ -1509,8 +1510,13 @@ void ip_send_reply(struct sock *sk, stru
sk->sk_priority = skb->priority;
sk->sk_protocol = ip_hdr(skb)->protocol;
sk->sk_bound_dev_if = arg->bound_dev_if;
- ip_append_data(sk, &fl4, ip_reply_glue_bits, arg->iov->iov_base, len, 0,
- &ipc, &rt, MSG_DONTWAIT);
+ err = ip_append_data(sk, &fl4, ip_reply_glue_bits, arg->iov->iov_base,
+len, 0, &ipc, &rt, MSG_DONTWAIT);
+ if (unlikely(err)) {
+ ip_flush_pending_frames(sk);
+ goto out;
+ }
+
if ((skb = skb_peek(&sk->sk_write_queue)) != NULL) {
if (arg->csumoffset >= 0)
*((__sum16 *)skb_transport_header(skb) +
@@ -1519,7 +1525,7 @@ void ip_send_reply(struct sock *sk, stru
skb->ip_summed = CHECKSUM_NONE;
ip_push_pending_frames(sk, &fl4);
}
-
+out:
bh_unlock_sock(sk);
ip_rt_put(rt);
--
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.2 20/27] net: sctp: fix memory leak in auth key management
3.2.66-rc1 review patch. If anyone has any objections, please let me know.
--
From: Daniel Borkmann
commit 4184b2a79a7612a9272ce20d639934584a1f3786 upstream.
A very minimal and simple user space application allocating an SCTP
socket, setting SCTP_AUTH_KEY setsockopt(2) on it and then closing
the socket again will leak the memory containing the authentication
key from user space:
unreferenced object 0x8800837047c0 (size 16):
comm "a.out", pid 2789, jiffies 4296954322 (age 192.258s)
hex dump (first 16 bytes):
01 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00
backtrace:
[] kmemleak_alloc+0x4e/0xb0
[] __kmalloc+0xe8/0x270
[] sctp_auth_create_key+0x23/0x50 [sctp]
[] sctp_auth_set_key+0xa1/0x140 [sctp]
[] sctp_setsockopt+0xd03/0x1180 [sctp]
[] sock_common_setsockopt+0x14/0x20
[] SyS_setsockopt+0x71/0xd0
[] system_call_fastpath+0x12/0x17
[] 0x
This is bad because of two things, we can bring down a machine from
user space when auth_enable=1, but also we would leave security sensitive
keying material in memory without clearing it after use. The issue is
that sctp_auth_create_key() already sets the refcount to 1, but after
allocation sctp_auth_set_key() does an additional refcount on it, and
thus leaving it around when we free the socket.
Fixes: 65b07e5d0d0 ("[SCTP]: API updates to suport SCTP-AUTH extensions.")
Signed-off-by: Daniel Borkmann
Cc: Vlad Yasevich
Acked-by: Neil Horman
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
net/sctp/auth.c | 2 --
1 file changed, 2 deletions(-)
--- a/net/sctp/auth.c
+++ b/net/sctp/auth.c
@@ -866,8 +866,6 @@ int sctp_auth_set_key(struct sctp_endpoi
list_add(&cur_key->key_list, sh_keys);
cur_key->key = key;
- sctp_auth_key_hold(key);
-
return 0;
nomem:
if (!replace)
--
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.2 08/27] net: sctp: fix NULL pointer dereference in af->from_addr_param on malformed packet
3.2.66-rc1 review patch. If anyone has any objections, please let me know.
--
From: Daniel Borkmann
commit e40607cbe270a9e8360907cb1e62ddf0736e4864 upstream.
An SCTP server doing ASCONF will panic on malformed INIT ping-of-death
in the form of:
INIT[PARAM: SET_PRIMARY_IP] >
While the INIT chunk parameter verification dissects through many things
in order to detect malformed input, it misses to actually check parameters
inside of parameters. E.g. RFC5061, section 4.2.4 proposes a 'set primary
IP address' parameter in ASCONF, which has as a subparameter an address
parameter.
So an attacker may send a parameter type other than SCTP_PARAM_IPV4_ADDRESS
or SCTP_PARAM_IPV6_ADDRESS, param_type2af() will subsequently return 0
and thus sctp_get_af_specific() returns NULL, too, which we then happily
dereference unconditionally through af->from_addr_param().
The trace for the log:
BUG: unable to handle kernel NULL pointer dereference at 0078
IP: [] sctp_process_init+0x492/0x990 [sctp]
PGD 0
Oops: [#1] SMP
[...]
Pid: 0, comm: swapper Not tainted 2.6.32-504.el6.x86_64 #1 Bochs Bochs
RIP: 0010:[] []
sctp_process_init+0x492/0x990 [sctp]
[...]
Call Trace:
[] ? sctp_bind_addr_copy+0x5d/0xe0 [sctp]
[] sctp_sf_do_5_1B_init+0x21b/0x340 [sctp]
[] sctp_do_sm+0x71/0x1210 [sctp]
[] ? sctp_endpoint_lookup_assoc+0xc9/0xf0 [sctp]
[] sctp_endpoint_bh_rcv+0x116/0x230 [sctp]
[] sctp_inq_push+0x56/0x80 [sctp]
[] sctp_rcv+0x982/0xa10 [sctp]
[] ? ipt_local_in_hook+0x23/0x28 [iptable_filter]
[] ? nf_iterate+0x69/0xb0
[] ? ip_local_deliver_finish+0x0/0x2d0
[] ? nf_hook_slow+0x76/0x120
[] ? ip_local_deliver_finish+0x0/0x2d0
[...]
A minimal way to address this is to check for NULL as we do on all
other such occasions where we know sctp_get_af_specific() could
possibly return with NULL.
Fixes: d6de3097592b ("[SCTP]: Add the handling of "Set Primary IP Address"
parameter to INIT")
Signed-off-by: Daniel Borkmann
Cc: Vlad Yasevich
Acked-by: Neil Horman
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
net/sctp/sm_make_chunk.c | 3 +++
1 file changed, 3 insertions(+)
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -2570,6 +2570,9 @@ do_addr_param:
addr_param = param.v + sizeof(sctp_addip_param_t);
af = sctp_get_af_specific(param_type2af(param.p->type));
+ if (af == NULL)
+ break;
+
af->from_addr_param(&addr, addr_param,
htons(asoc->peer.port), 0);
--
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/
