Re: [PATCH 2/3] binder: do not initialize locals passed to copy_from_user()
On Wed, Feb 26, 2020 at 03:58:41PM +0100, Alexander Potapenko wrote: > On Tue, Feb 25, 2020 at 4:24 PM Alexander Potapenko wrote: > > > > On Tue, Feb 25, 2020 at 5:18 AM Kees Cook wrote: > > > > > > On Mon, Feb 24, 2020 at 04:35:00PM +0100, gli...@google.com wrote: > > > > Certain copy_from_user() invocations in binder.c are known to > > > > unconditionally initialize locals before their first use, like e.g. in > > > > the following case: > > > > > > > > struct binder_transaction_data tr; > > > > if (copy_from_user(&tr, ptr, sizeof(tr))) > > > > return -EFAULT; > > > > > > > > In such cases enabling CONFIG_INIT_STACK_ALL leads to insertion of > > > > redundant locals initialization that the compiler fails to remove. > > > > To work around this problem till Clang can deal with it, we apply > > > > __do_not_initialize to local Binder structures. > > > > > > It should be possible to write a Coccinelle script to identify all these > > > cases. (i.e. a single path from struct declaration to copy_from_user()) > > > and apply the changes automatically. This script could be checked into > > > scripts/coccinelle/ to help keep these markings in sync... > > > > The following script: > > > > = > > @local_inited_by_cfu@ > > attribute name __no_initialize; > > identifier var; > > type T; > > statement stmt; > > @@ > > T var > > +__no_initialize > > ; > > if (copy_from_user(&var,..., sizeof(var))) stmt > > = > > > > seems to do the job, but this transformation isn't idempotent: it > > inserts __no_initialize every time Coccinelle is invoked. > > It's hard to work around this problem, as attributes may only be parts > > of +-lines (i.e. I cannot write a rule that matches "T var > > __no_initialize") > > This one: > > > @match@ > type T; > identifier var; > statement stmt; > fresh identifier var_noinit = var##" __no_initialize"; > @@ > -T var; > +T var_noinit; > ... > if (copy_from_user(&var,..., sizeof(var))) stmt > > is better, because it: > - uses a "fresh identifier" hack instead of dealing with attributes > (which aren't supported by spatch 1.0.4) > - seems to be idempotent because of that hack. > > I'll regenerate the binder patch using that script and will look into > enhancing it and committing it to scripts/coccinelle. Cool; sounds good! -- Kees Cook ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RESEND PATCH v3 02/17] media: v4l2-fwnode: Pass notifier to v4l2_async_register_fwnode_subdev()
Hi Sakari, Thanks for the feedback. On 2/25/20 7:07 AM, Sakari Ailus wrote: Hi Steve, On Sat, Feb 15, 2020 at 11:41:21AM -0800, Steve Longerbeam wrote: Instead of allocating a notifier in v4l2_async_register_fwnode_subdev(), have the caller provide one. This allows the caller to implement notifier ops (bind, unbind). The caller is now responsible for first initializing its notifier with a call to v4l2_async_notifier_init(). Signed-off-by: Steve Longerbeam Instead of improving v4l2_async_register_fwnode_subdev(), could you convert the users (IMX driver in this case) to call the preferred APIs instead? I presume you mean using v4l2_async_notifier_add_fwnode_remote_subdev(). Ok, I'll convert to use that API. Steve As the lines below show, v4l2_async_register_fwnode_subdev() has only two users left --- the other one of which is the IMX driver. After converting these two, we could just remove this API. See e.g. drivers/media/pci/intel/ipu3/ipu3-cio2.c and drivers/media/platform/omap3isp/isp.c for examples. --- Changes in v3: - added the missing calls to unregister/cleanup the new subdev notifiers. Reported by Rui Silva. --- drivers/media/platform/video-mux.c | 8 +++- drivers/media/v4l2-core/v4l2-fwnode.c | 11 +-- drivers/staging/media/imx/imx6-mipi-csi2.c | 7 ++- drivers/staging/media/imx/imx7-media-csi.c | 7 ++- drivers/staging/media/imx/imx7-mipi-csis.c | 9 - include/media/v4l2-fwnode.h| 12 6 files changed, 36 insertions(+), 18 deletions(-) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH] staging: exfat: remove symlink feature : Additional patch
Thanks for comment. > Then this should have been [PATCH v2], and the fixed version [PATCH > v3] 2nd patch(Additional patch) not include 1st patch(RFC PATCH). And the 1st patch has been merged into 'staging-next'. Now I can't decide. a) Add only version information to the 2nd patch. b) Merge the 1st and 2nd patches. Which is better for v3? -- Kohada Tetsuhiro ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re:Ms. Reem
Hello, My name is Reem Ebrahim Al-Hashimi, I am the "Minister of state and Petroleum" also "Minister of State for International Cooperation" in UAE. I write to solicit for your partnership in claiming of $47Million from a Financial Home in Cambodia. The aforementioned fund $47 Million is my share percentage from my Oil/Gas deal with Cambodia/Vietnam Government within 2013/2014, influentially I don't want my government to know about the fund. If this proposal interests you, let me know by sending me an email and I will send to you detailed Information on how this business would be successfully transacted. Be informed that nobody knows about the secret of this fund except me and I know how to carry out the entire transaction. Furthermore, as a Minister of Petroleum, I am not allowed to be part of such a deal, because it's against my country's professional practice policy. So I am compelled to ask that you will stand on my behalf and receive this fund into any account that is solely controlled by you. I will compensate you with 30% of the total amount involved as gratification for being my partner in the transfer. Reply to my private email as stated: reemal-hash...@yandex.com Regards, Reem Ebrahim Al-Hashimi ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: exfat: remove symlink feature : Additional patch
On Thu, 27 Feb 2020 02:14:02 +, "kohada.tetsuh...@dc.mitsubishielectric.co.jp" said: > Thanks for comment. > > > Then this should have been [PATCH v2], and the fixed version [PATCH > > v3] > > 2nd patch(Additional patch) not include 1st patch(RFC PATCH). > And the 1st patch has been merged into 'staging-next'. > Now I can't decide. > a) Add only version information to the 2nd patch. > b) Merge the 1st and 2nd patches. > > Which is better for v3? The first part is in-tree, so we don't re-visit it in this case. You want a new patch that consists of *only* the second set of changes, and the changelog for the changes for that patch. pgpr1Q7WSXJa8.pgp Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3] staging: exfat: remove symlink feature
Completely remove symlink codes and definitions.
In the previous patch, it was not completely removed.
Reviewed-by: Takahiro Mori
Signed-off-by: Tetsuhiro Kohada
---
Changes in v3:
- fixed subject line
Changes in v2:
- previous patch didn't completely remove it
drivers/staging/exfat/exfat.h | 3 ---
drivers/staging/exfat/exfat_core.c | 3 ---
drivers/staging/exfat/exfat_super.c | 27 ---
3 files changed, 33 deletions(-)
diff --git a/drivers/staging/exfat/exfat.h b/drivers/staging/exfat/exfat.h
index 4a0a481fe010..cd3479fc78ba 100644
--- a/drivers/staging/exfat/exfat.h
+++ b/drivers/staging/exfat/exfat.h
@@ -63,7 +63,6 @@
#define TYPE_VOLUME0x0103
#define TYPE_DIR 0x0104
#define TYPE_FILE 0x011F
-#define TYPE_SYMLINK 0x015F
#define TYPE_CRITICAL_SEC 0x0200
#define TYPE_STREAM0x0201
#define TYPE_EXTEND0x0202
@@ -198,13 +197,11 @@ static inline u16 get_row_index(u16 i)
#define ATTR_VOLUME0x0008
#define ATTR_SUBDIR0x0010
#define ATTR_ARCHIVE 0x0020
-#define ATTR_SYMLINK 0x0040
#define ATTR_EXTEND0x000F
#define ATTR_RWMASK0x007E
/* file creation modes */
#define FM_REGULAR 0x00
-#define FM_SYMLINK 0x40
#define NUM_UPCASE 2918
diff --git a/drivers/staging/exfat/exfat_core.c
b/drivers/staging/exfat/exfat_core.c
index d30dc050411e..941094b08dd9 100644
--- a/drivers/staging/exfat/exfat_core.c
+++ b/drivers/staging/exfat/exfat_core.c
@@ -844,9 +844,6 @@ static void exfat_set_entry_type(struct dentry_t *p_entry,
u32 type)
} else if (type == TYPE_FILE) {
ep->type = 0x85;
SET16_A(ep->attr, ATTR_ARCHIVE);
- } else if (type == TYPE_SYMLINK) {
- ep->type = 0x85;
- SET16_A(ep->attr, ATTR_ARCHIVE | ATTR_SYMLINK);
}
}
diff --git a/drivers/staging/exfat/exfat_super.c
b/drivers/staging/exfat/exfat_super.c
index c7bc07e91c45..6f3b72eb999d 100644
--- a/drivers/staging/exfat/exfat_super.c
+++ b/drivers/staging/exfat/exfat_super.c
@@ -320,8 +320,6 @@ static inline mode_t exfat_make_mode(struct exfat_sb_info
*sbi, u32 attr,
if (attr & ATTR_SUBDIR)
return (mode & ~sbi->options.fs_dmask) | S_IFDIR;
- else if (attr & ATTR_SYMLINK)
- return (mode & ~sbi->options.fs_dmask) | S_IFLNK;
else
return (mode & ~sbi->options.fs_fmask) | S_IFREG;
}
@@ -2399,24 +2397,6 @@ static const struct inode_operations
exfat_dir_inode_operations = {
/*==*/
/* File Operations */
/*==*/
-static const char *exfat_get_link(struct dentry *dentry, struct inode *inode,
- struct delayed_call *done)
-{
- struct exfat_inode_info *ei = EXFAT_I(inode);
-
- if (ei->target) {
- char *cookie = ei->target;
-
- if (cookie)
- return (char *)(ei->target);
- }
- return NULL;
-}
-
-static const struct inode_operations exfat_symlink_inode_operations = {
- .get_link = exfat_get_link,
-};
-
static int exfat_file_release(struct inode *inode, struct file *filp)
{
struct super_block *sb = inode->i_sb;
@@ -2688,13 +2668,6 @@ static int exfat_fill_inode(struct inode *inode, struct
file_id_t *fid)
i_size_write(inode, info.Size);
EXFAT_I(inode)->mmu_private = i_size_read(inode);
set_nlink(inode, info.num_subdirs);
- } else if (info.attr & ATTR_SYMLINK) { /* symbolic link */
- inode->i_generation |= 1;
- inode->i_mode = exfat_make_mode(sbi, info.attr, 0777);
- inode->i_op = &exfat_symlink_inode_operations;
-
- i_size_write(inode, info.Size);
- EXFAT_I(inode)->mmu_private = i_size_read(inode);
} else { /* regular file */
inode->i_generation |= 1;
inode->i_mode = exfat_make_mode(sbi, info.attr, 0777);
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RESEND PATCH v3 02/17] media: v4l2-fwnode: Pass notifier to v4l2_async_register_fwnode_subdev()
On Wed, Feb 26, 2020 at 03:50:04PM -0800, Steve Longerbeam wrote: > Hi Sakari, > > Thanks for the feedback. > > > On 2/25/20 7:07 AM, Sakari Ailus wrote: > > Hi Steve, > > > > On Sat, Feb 15, 2020 at 11:41:21AM -0800, Steve Longerbeam wrote: > > > Instead of allocating a notifier in v4l2_async_register_fwnode_subdev(), > > > have the caller provide one. This allows the caller to implement > > > notifier ops (bind, unbind). > > > > > > The caller is now responsible for first initializing its notifier with a > > > call to v4l2_async_notifier_init(). > > > > > > Signed-off-by: Steve Longerbeam > > Instead of improving v4l2_async_register_fwnode_subdev(), could you convert > > the users (IMX driver in this case) to call the preferred APIs instead? > > I presume you mean using v4l2_async_notifier_add_fwnode_remote_subdev(). Ok, > I'll convert to use that API. Thanks, Steve! -- Sakari Ailus ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
